文件被 rm 之后还能救回来吗？一文掌握 trash-cli 命令行回收站的完整用法

文件被 rm 之后还能救回来吗一文掌握 trash-cli 命令行回收站的完整用法【免费下载链接】trash-cliCommand line interface to the freedesktop.org trashcan.项目地址: https://gitcode.com/gh_mirrors/tr/trash-cli如果你在服务器上做过运维多半经历过这样的时刻一条rm -rf敲下去回车之后才猛然想起目录里还有一份没备份的配置又或者在某次清理磁盘时把同事刚生成的报表一起删了。rm的好处是干脆利落代价是没有任何后悔药。这时候你会意识到删除操作真正缺的不是更快的删除而是一条安全的退路。trash-cli 正是为这个缺口设计的——它是 freedesktop.org 回收站标准的命令行实现让你在终端里也能像桌面环境那样先删进回收站、随时可恢复而且和你 GNOME、KDE 图形界面里的回收站是同一个。先想清楚一个问题为什么rm不适合当日常删除工具很多人第一次接触 trash-cli 时会问我用了十几年rm也没出过大事。这个判断基本靠运气。rm的设计目标是立即释放空间它既不询问、也不留痕更没有后悔这个功能。下面这张表能直观看出它和回收站式删除的本质差异维度rm直接删除trash-cli 回收站删除删除后是否可恢复不可除非提前备份可以随时用 restore 找回是否记录原路径不记录每个文件都记录原始位置是否记录删除时间不记录写入 DeletionDate 字段是否跨分区安全与回收站无关遵循同卷优先规则是否适合放进脚本危险误操作代价高安全可配合 cron 自动清理rm不是不能用而是应该留给确认不要了的场景。日常的、试探性的、可能还要反悔的删除都应该走回收站。trash-cli 的价值就是把这个习惯变成一条命令的事。三分钟跑通第一个最小示例安装方式按自己的环境选一种即可。最通用的是 pip想隔离环境就用 pipxDebian/Ubuntu 用户也可以直接用系统包管理器pip install trash-cli # 或者 pipx install trash-cli装好之后验证一下三个命令是否就位trash-put --version现在做一个完整的删除 → 查看 → 恢复闭环。先造一个测试文件mkdir -p ~/tmp/trash-demo echo 这是一份重要的草稿 ~/tmp/trash-demo/meeting-notes.txt把它送进回收站trash-put ~/tmp/trash-demo/meeting-notes.txt确认原文件已经不在原位然后列出回收站内容trash-list输出会类似这样每一行左侧是删除时间右侧是文件被删除前的完整路径2026-08-14 18:20:11 /home/you/tmp/trash-demo/meeting-notes.txt最后把它恢复回来trash-restore 0 2026-08-14 18:20:11 /home/you/tmp/trash-demo/meeting-notes.txt What file to restore [0..0]: 0输入序号0回车文件就回到了原位内容分毫不差。到这里你已经掌握了 trash-cli 最核心的三个动作trash-put送进回收站、trash-list查看清单、trash-restore按序号恢复。回收站里到底存了什么一份.trashinfo的前世今生用过图形界面回收站的人可能会好奇trash-cli 怎么保证和桌面环境同一个回收站答案藏在目录结构和元数据文件里。主分区通常是家目录所在卷的回收站位于~/.local/share/Trash/ ├── files/ # 被删除文件的真实存放处 └── info/ # 与文件一一对应的元数据你删掉的meeting-notes.txt会变成files/meeting-notes.txt同时在info/下生成一个meeting-notes.txt.trashinfo。这个元数据文件是纯文本格式遵循 freedesktop.org 的 Trash 规范核心内容就两行[Trash Info] Path/home/you/tmp/trash-demo/meeting-notes.txt DeletionDate2026-08-14T18:20:11Path记录原始位置带 URL 编码DeletionDate记录精确到秒的删除时间。trash-list读的就是这两个字段trash-restore靠Path决定把文件放回哪里。想深入看解析逻辑可以读trashcli/parse_trashinfo/目录下的实现。跨分区的情况会稍微复杂如果被删文件不在主分区上trash-cli 会优先在该分区的挂载点创建.Trash/uid目录规则细节写在docs/trash-directories.txt里。日常使用你基本感知不到这个过程只要知道每个分区的文件都会就近进回收站就够了。高频场景批量恢复、按时间清理、按模式定点删除上面是最小闭环实际使用中还有三个高频操作值得单独拎出来。批量恢复一次选多个。trash-restore的输入框支持逗号分隔和区间写法。比如回收站里有 5 个文件你想恢复第 1、2、4、5 个What file to restore [0..4]: 0-1,3-4它会依次把选中的文件全部放回原位。注意恢复时如果原位置已经有同名文件默认会拒绝覆盖并给出提示确认想覆盖的话可以用--overwrite参数。按时间清理给回收站设保质期。回收站最大的隐患是只进不出磁盘迟早被占满。trash-empty支持天数参数只删除超过指定天数的文件# 清空 30 天前的所有回收站文件 trash-empty 30不带参数就是全部清空请谨慎使用。这个保质期逻辑对定期清理特别有用后面会讲怎么挂到 cron 上。按模式定点删除而不是全部清空。有时候你只想从回收站里挑出某一类文件彻底删掉trash-rm干的就是这件事trash-rm *.tmp trash-rm /home/you/tmp/trash-demo/*它的匹配规则基于原始路径以/开头的模式匹配完整路径否则匹配文件名。这里有一个新手必踩的坑——模式一定要加引号。不加引号的话Shell 会在命令执行前就把*.tmp展开成当前目录下的文件列表trash-rm收到的是文件名而不是模式结果完全不是你想要的行为。容易被忽略的两个坑坑一回收站允许同名文件共存靠后缀区分。如果你先后删除两个同名文件比如两次trash-put report.pdf第二个文件在files/里会自动改名成report_1.pdf依次递增。这个细节平时无感但如果你用脚本直接扫描files/目录做统计就会被后缀搞晕。好在trash-list和trash-restore都基于.trashinfo工作展示的始终是原始路径所以所有操作都应该走这几个命令而不是直接翻files/目录。坑二trash-put和rm的参数语义不同。有人习惯给rm加别名指向trash-put项目文档里明确不建议这么做——两者语义并不完全一致比如rm删目录需要-r而trash-put不需要混用别名会让行为变得难以预测。更好的替代方案是让rm在敲下去之前拦你一下alias rmecho This is not the command you are looking for.; false真想用rm时前面加反斜杠绕过别名即可\rm file。这个别名只在交互式 Shell 里生效不会影响脚本里的正常rm调用。把回收站接进自动化定时清理与脚本集成trash-cli 的另一个重要场景是脚本和定时任务。比如给回收站设置30 天自动过期一行 cron 就能搞定(crontab -l ; echo daily $(which trash-empty) 30) | crontab -以后每天都会自动清掉超过 30 天的回收站文件旧文件既不占空间新误删的又还在保质期内。写进部署脚本时trash-put因为不会真的删数据比rm安全得多配合trash-list做巡检、trash-restore做救援就构成了一套完整的删除生命周期管理。源码层面如果想了解命令的组装方式入口分别在trashcli/put/main.pytrash-put、trashcli/list/trash-list、trashcli/restore/trash-restore想改行为、加功能可以从这几个目录入手。下一步行动清单如果你刚接触 trash-cli按这个顺序上手最快装好之后用本文的示例把删除 → 列表 → 恢复完整跑一遍记住恢复要输入序号把trash-put纳入日常习惯替代那些可能还要反悔的rm调用给回收站设一个定时清理任务避免只进不出把trash-rm *.模式的引号规则写进团队文档这是最常见的误用点排查存量脚本凡是直接删文件的地方评估是否值得换成先入回收站再定期清空的模式。误删是每个终端用户的必修课trash-cli 不能让你不犯错但能让错误变得可以挽回——这大概是对删除这件事最好的设计。【免费下载链接】trash-cliCommand line interface to the freedesktop.org trashcan.项目地址: https://gitcode.com/gh_mirrors/tr/trash-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考