这是一个创建于 2848 天前的主题，其中的信息可能已经有所发展或是发生改变。
rm-protection
GitLab 的惨剧想必大家都知道了：rm -rf了生产服务器上的数据库。常在河边走，哪能不湿鞋。即便是再认真，总是有失误的风险。
现在网上已经流行了数种方法： rm -i , trash-cli 等等。rm -i 显然并不实用：想必没人能忍受每个文件都被问一次？况且就 GitLab 的情况，rm -i并不能起保护作用。trash-cli相当于启用了回收站，但是这又会带来一些小麻烦（比如在磁盘被 log 挤爆的情况下）。
rm-protection 则采取了一种全新的思路：由用户自行设置一个安全问题来保护文件，在删除时询问相应的问题。想象一下，若 YP 在执行删除时突然被问一句：「 Which server are you on? 」，还会出现这样的惨剧吗？
快速开始
rm-protection 几乎完全兼容rm，因此可以作为 alias 使用。
-
从 PyPi 中安装并为
rm-p创建 alias 。pip install rm-protection & alias rm="rm-p" -
使用
protect命令保护你想要保护的文件或者文件夹。 -
Happy rm-ing!
原理
rm-protection 获取 arguments 后，会逐一检测是否存在 .<filename>.rm-protection 文件。若存在，则询问用户，否则将不再传递这个 argument 。安全的 argument 将被传递给 rm 进行删除。
栗子：
它也能保护批量的递归删除：
与其他工具的对比
参见 GitHub 中的表格。
未来？
若是这个工具能被推广使用，团队协作之间可以大有功用。在软件、文件分发时，分发者可以提前保护文件防止误删。在开发和部署时也可提前保护文件，防止在生产环境中的误删。
贡献
Github 欢迎 PR, 提 Issue 或者 Star ：）
第 1 条附言 · 2017-02-04 09:28:24 +08:00
FAQ
使用栗子？
rm -rf database
「你删的是啥数据库」
「测试」
「滚！」
简单问题复杂化？
在特定的场合复杂化我觉得是有益的，比如 GitHub 会在你删除 repo 的时候让你确认 repo 的名字。
事实上 rm-protection 并不影响日常操作。只有当遇到你特定保护的文件时才会提示并提供尽可能的保护。
rm -i 或者 alias rm="mv" 又或者 trash，下一题?
每个文件都问，你受得了（当然取决于个人了，我是受不了）？那么你听说过「狼来了」的故事吗？yes | rm -i
trash 类的方案并不能从源头上解决问题，当你想释放空间的时候，很容易随手就清空了垃圾桶。
已经有 XXX 了，好处在哪？
就我所知除了 Safe-rm 之外，没有类似机制的轮子出现。你也可以看看这里与其他机制的对比：https://github.com/alanzchen/rm-protection/blob/master/README.md#comparison-with-alternative-methods
我去 Python 3? 你搞笑？
嘛确实不太合适（逃。其实我完全不 care 到底有没有人用我的 implementation，唯一想做的是向社区提供这么一个机制的提案。
若是社区能接受，这轮子很快可以被移植到任何语言或者任何平台，甚至被包括在 GNU coreutils 里。唯一需要统一的是，是否能够接受 .rm-protection 这样的保护机制。
36 条回复 • 2017-02-05 14:59:28 +08:00
 |
1
qiuai 2017-02-03 22:26:59 +08:00
如果是为了服务器多的情况下准备的,为什么不直接设置问题为服务器的名字.
比如提前在文件中定义服务器的名字为 Prod-1 那么删除的时候要输入 Prod-1.如果要删除 2.那么不会去输入-1 吧? 如果输入了-2..那就可以直接拒绝了嘛... 弄一个问题上去,好像有点复杂? |
 |
2
jingniao 2017-02-03 22:40:03 +08:00 via Android
其实我觉得如果给 rm 添加个功能，读取配置文件避开
|
|
3
jingniao 2017-02-03 22:40:37 +08:00 via Android
重要文件，如果要删除，加个参数
|
 |
4
discrete OP @qiuai 你确实可以设置为问服务器的名字呀。问题和答案都是用户在保护文件时设定的。在 Prod-1 上你的回答应该是 Prod-1 ，在 Prod-2 上应该是 Prod-2 。
与丢失重要文件的相比，我觉得问一个问题的时间挺值的。 |
|
5
discrete OP @jingniao 这个轮子已经有了，叫 Safe-rm 。相比之下我觉得 rm-protection 的方式更加灵活一点。假定你不问问题的话，加个参数还不是顺手事情？（想象一下 YP 的状况。
|
 |
6
Akagi201 2017-02-03 22:44:20 +08:00
建议用 bash 重写, 不依赖任何环境.
|
|
7
discrete OP @Akagi201 这种轻量级的程序确实应该用 bash 写……不过现在哪台机器上没个 python 呢
不过当然欢迎各种语言的 implementation 。只要 .rm-protection 这个格式互相能兼容就行。 |
 |
8
snnn 2017-02-03 22:55:12 +08:00 via Android
然后硬盘爆了，数据库写入失败，挂掉了
|
 |
9
xuboying 2017-02-03 23:46:39 +08:00
300G 的数据复制一下，也没多久时间，关键还是要做好备份啊
rm 再小心还是会有错误的时候。 问题的关键点还是备份做的不好啊 |
 |
10
Doubear 2017-02-04 01:40:22 +08:00  1
which server are you on?
??? [我不是在测试环境么？？？] > dev server …… [卧槽哪来那么多文件？！！糟糕这尼玛不是测试服……] 《 MySQL 从删库到跑路》 |
 |
11
chuhades 2017-02-04 02:02:42 +08:00
➜ ~ grep trash .zshrc
alias trash='gvfs-trash' |
 |
13
yangqi 2017-02-04 02:19:41 +08:00
你这个显然解决不了类似这次 gitlab 的问题。人家不是误删文件，而且误以为自己在 slave 机器上，结果是在主机上。
即使有了各种确认也没用 |
 |
16
cxbig 2017-02-04 03:32:54 +08:00
我们家是在 PS1 上直接加机器代号， admin 、 backend 、 frontend-1~x 。根本不会弄混。
|
 |
17
WildCat 2017-02-04 04:13:45 +08:00
|
 |
18
SharkIng 2017-02-04 06:53:29 +08:00
显然这个也不能完全解决问题， Gitlab 的情况是程序员太累，以为自己在 db2 结果实际是 db1. 即使有这么个问题也有可能因为太累输错之类的。
|
 |
19
eccstartup 2017-02-04 06:56:26 +08:00
叫 `rm-gitlab` （逃
|
 |
20
deamwork 2017-02-04 07:42:55 +08:00 via Android
|
 |
21
loading 2017-02-04 07:45:01 +08:00 via Android
简单问题复杂化，大师级！
|
|
22
discrete OP @SharkIng 当你必须输入 I'm going to delete production database 的时候难道还不会心里一惊 2333
当然了不可能所谓完全解决问题，只是试图以最小的日常影响（比如与 rm -i 相比）做到最大的保护。 |
 |
23
ayayui 2017-02-04 08:46:30 +08:00
rm 列出要删除的文件，确认后才删除。
|
 |
24
phrack 2017-02-04 08:54:22 +08:00 via Android
也许允许人犯一些错误更好，不然世界就少了乐趣和故事了。
|
|
25
discrete OP @loading 在特定的场合复杂化我觉得是有益的，比如 GitHub 会在你删除 repo 的时候让你确认 repo 的名字。
这个工具同理，不会影响你 rm 的日常操作，但是在删除极其重要的文件时提供尽可能的保护。 |
|
26
discrete OP @cuebyte 嘛确实……（捂脸逃（其实当时不用 python2 只是因为 raw_input() 的问题，加个判断就兼容了。
|
 |
28
lanxyou 2017-02-04 09:15:14 +08:00
批量删除的时候会不会把保护文件先删除了？
|
 |
30
gfexfizv 2017-02-04 09:19:14 +08:00 via Android
可以 alias rm 为 move ，移动到一个垃圾文件夹里面
|
 |
31
harry890829 2017-02-04 09:21:09 +08:00
用 alias 重定义 rm 啊，改为 move ，然后丢到垃圾文件夹，定期清理垃圾文件夹就好了
|
 |
32
finian 2017-02-04 10:03:45 +08:00 1
稍微有点复杂了，不如 trash 的方案来得简单。不过这些方案都无法彻底避免杯具，人和流程都是不可靠的，唯有使用自动化工具才能最大程度地避免失误
|
 |
33
sox 2017-02-04 11:11:35 +08:00 via Android
npm i -g trash-cli
alias rm=“ trash ” |
|
34
discrete OP |
 |
35
qianguozheng 2017-02-05 14:39:16 +08:00
例子中的 gif 图片用什么工具获得的？
|
|
36
discrete OP @qianguozheng macOS 自带 QuickTime 录屏，然后 Google 里随便找了一个在线的视频转 gif 工具。
|
Select Language