Ente Locker 回收站Trash完全指南30 天保留、恢复与永久删除机制详解【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente在 Ente Locker 中删除条目时数据并不会被立即抹除而是先移入回收站Trash为你保留一段可反悔的缓冲期。本文以官方文档 trash.md 为核心结合 Ente 服务端Go与客户端Dart/Flutter源码完整讲解回收站的工作机制、删除/恢复/清空的完整操作流程以及背后的数据库设计与定时清理原理。读完本文你将掌握回收站的全部用法并能从源码层面理解 30 天保留期是如何实现的。回收站的核心机制Ente Locker 的回收站遵循一套简单而严谨的软删除 延迟硬删除模型核心规则如下删除即入站删除条目后它进入回收站而非立即消失为误删提供安全网保留 30 天回收站中的条目默认保留30 天到期永久删除超过 30 天后条目被服务端后台任务自动永久删除随时可恢复在永久删除之前的任意时刻你都可以把条目恢复到其原始收藏夹collection支持手动清空你可以手动清空回收站让条目立即被永久删除。这套机制的直观价值是既避免了一键删除带来的不可逆损失又通过明确的过期策略防止回收站无限膨胀。删除条目移入回收站在 Ente Locker 中删除一个条目的操作路径如下长按Long press你想要删除的条目点击出现的菜单图标选择Delete删除确认删除。条目随即被移入回收站。从客户端源码看这一动作最终通过CollectionsService.trashFile构造一个TrashRequest(fileID, collectionID)请求调用CollectionsApiClient.trash发送到服务端的POST /files/trash接口见 collections_api_client.dart随后触发本地回收站状态同步TrashService.syncTrash。查看回收站回收站视图的入口与操作如下在首页打开菜单点击Trash回收站查看所有已删除条目及其删除日期。客户端与服务端之间通过增量同步diff sync保持回收站状态一致TrashService.syncTrash会拉取服务端GetDiff接口返回的回收站变更新删除、已恢复、已永久删除的条目并据此更新本地数据库见 trash_service.dart。也就是说回收站列表不仅展示本地刚删除的条目也会反映你在其他设备上执行的删除/恢复操作。恢复条目Restore恢复是回收站最重要的后悔药功能打开回收站Trash点击要恢复的条目点击Restore恢复条目回到其原始收藏夹。在源码层面恢复动作由TrashService.restore实现客户端将待恢复文件的列表与目标收藏夹 ID 一起通过POST /collections/restore-files提交给服务端见 trash_service.dart。恢复成功后trash表中对应记录的is_restored标记会被置为true该条目不再被视为待删除对象。清空回收站删除全部条目Empty Trash打开回收站点击菜单图标选择Empty Trash清空回收站确认永久删除。[!WARNING] 清空回收站会永久删除其中所有条目此操作不可撤销。删除单个条目打开回收站点击想要永久删除的条目点击Delete permanently永久删除确认永久删除。这里的关键差异在于恢复Restore与永久删除Delete permanently是互斥的最终裁决。从服务端数据模型看trash表对这两者施加了状态约束——is_deleted与is_restored不能同时为真见 32_add_trash_table.up.sql从而保证每条记录的状态语义唯一。存储配额与回收站需要特别留意回收站中的条目仍然计入你的存储配额直到它们被真正永久删除无论是由 30 天到期自动触发还是你手动清空。这意味着仅靠删除并不能立刻释放存储空间。如果你迫切需要腾出配额请主动清空回收站或逐个执行永久删除。服务端实现回收站是如何工作的Ente 的回收站并非简单的延迟删除标记而是一套由数据库表、后台定时任务与任务队列协同运作的完整体系。以下从源码层面拆解其实现。数据模型trash表回收站的核心数据模型定义在 trash.go对应数据库表由迁移脚本 32_add_trash_table.up.sql 创建关键字段如下字段说明file_id文件 ID主键外键关联collection_filesuser_id/collection_id所属用户与收藏夹is_deleted是否已永久删除无法再恢复is_restored是否已被用户恢复delete_by计划永久删除的时间戳即30 天后的计算结果created_at/updated_at创建与更新时间微秒级表上还建有updated_at索引用于按时间分批处理与delete_by索引用于快速找出到期文件见 34_trash_delete_by_idx.up.sql。30 天保留期如何落地30 天这一规则最终体现在delete_by字段上条目进入回收站时服务端会写入delete_by 当前时间 30 天的时间戳。后台定时任务DeleteAgedTrashedFiles见 trash.go 控制器会定期执行通过分布式任务锁DeleteAgedTrashedFiles确保同一时刻只有一个实例在跑查询所有delete_by 当前时间且is_deleted false、is_restored false的文件见 repo/trash.go按用户分组执行真正的永久删除物理删除文件与记录。换句话说只有既未恢复、又未删除的到期条目才会被物理清除——已恢复的条目会继续存在已手动永久删除的条目则早已离开回收站。清空与恢复的接口层服务端为客户端提供了一组明确的回收站接口见 trash.go 模型 与 trash.go 控制器删除条目DeleteTrashFilesRequest携带fileIDs→ 移入回收站清空回收站EmptyTrashRequest要求客户端携带lastUpdatedAt时间戳——服务端只清空该时间戳之前的条目避免后台排队中的任务误删刚刚新入站的条目删除收藏夹TrashCollectionV3Request通过keepFiles布尔值决定是仅删收藏夹、文件移入回收站还是连同文件一并处理。清空操作本身是异步的接口先记录请求随后由ProcessEmptyTrashRequests从任务队列中批量消费区分 Photos 与 Locker 两个队列并对每个用户/收藏夹加锁串行处理防止并发冲突见 trash.go 控制器。客户端视角本地同步与离线一致性在 Ente Locker 客户端中回收站由TrashService统一管理它在应用启动main.dart中TrashService.instance.init与每次删除/恢复/清空操作后自动触发syncTrash()实现与服务端的增量同步见 trash_service.dart。同步内容包括新删除的条目进入本地回收站视图已恢复的条目从回收站视图移除并回到收藏夹已永久删除的条目从回收站视图移除。本地数据库中还维护了一张trash_files表见 locker_db.dart使得回收站列表在离线状态下也能正常查看。常见问题速查以下问答同样收录于 FAQ 文档与本文主题直接相关删除的条目在回收站保留多久30 天到期后自动永久删除对应锚点 locker-trash-retention。30 天后还能找回吗不能。30 天后条目被永久删除且无法恢复若有保留需求请在到期前恢复对应锚点 locker-recover-after-30-days。回收站占用存储吗占用。条目在被永久删除到期自动删除或手动清空之前一直计入你的存储配额对应锚点 locker-trash-storage。小结Ente Locker 的回收站是一个典型的软删除 延迟物理删除设计用户层面它提供 30 天后悔期、随时恢复与手动清空三种能力工程层面它以trash表的delete_by时间戳为核心配合后台定时任务、任务队列与分布式锁可靠地完成到期清理与并发控制。理解这套机制你既能更安全地管理自己的数据也能举一反三地借鉴其实现思路。【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考