Some weeks ago, I accidentally deleted half of my /usr/lib. I didn't lose anything important and was able to restore everything (thanks to my Ctrl+C'ing the process in time) but that user error did strike me as too easy to make (apparently, I'm not alone). So I started thinking about how I could prevent something like that from happening again.
I realized one thing: there is no way I would ever want to delete /usr or /etc for example. I figured that "rm" should, by default, refuse to delete certain critical directories (or files). Of course, that would be a very controversial patch to "rm" itself and the chances of this approach succeeding were pretty close to zero.
So instead, I decided to build a wrapper around "rm" which prevents the deletion of important files by checking each one against a blacklist. Anything you add to the blacklist will not be deletable using "rm" unless you override this protection by calling "rm.real" directly.
This tool, safe-rm, ships with a default system-wide configuration file (/etc/safe-rm.conf), but each user can supplement that list of "protected" directories and files by adding lines to ~/.safe-rm.
Debian and Ubuntu packages are available from the usual places.
There are of course different approaches to preventing these kinds of problems...
I did this with an alias:
"alias rm='rm -i'"
I use "\rm" when I'm sure about what I'm deleting but most of the time, I prefer to go through the confirmation. Too many files disappeared because of a rushed removal action.
Very very dangerous command
Do in a folder
rm -rf .*
for me, it's a 'rm' bug because
rm -rf *
Do not remove dot file.
But rm -rf .* remove .. folder !
rm -rf .*
And everything is remove on your disk ;-(
I think you can a this to your tool.
Sytoka
This is an unfortunate error to make, but no, you're definitely not alone. One time I accidently deleted half of the CEO's home directory on the file server.
(Bonus question: If you're trying to get rid of all the hidden files in a directory, is "rm -rf .*" a bad idea?)
Anyway, it wouldn't be too difficult* to write a shell-replacement for 'rm' which makes an inode-based copy into a .trash directory before deleting, which the user can then empty out at their leisure. I suppose moving the file to the user's .trash directory would suffice too, although speed and disk space become a problem when more than one partitions are involved. As an aside, is there a non-trivial way to determine the current mountpoint's root from pwd? Oh well. Glad you caught this before it got out of hand, and take solace in the fact that you're definitely not the only person to do it.
* - implementation is left as an exercise to the reader
The replacement of /bin/rm is a bad idea IMO.
It's not as evil at aliasing rm to rm -i (which you mention as one of the alternative approaches) but it's going down a similar road.
The first problem is that if you come to rely on this functionality, and so feel slightly safer when using rm, what happens when you're on a system where safe-rm is not installed? (this is the thing that makes the rm -i alias totally evil -- I'll admit that this is much less of an issue with safe-rm, as it's not like you're going to get into that habit of typing rm *, assuming there's a -i to save you)
Secondly, what happens when a pre/postinst comes along that really needs to delete something that you thought should never be deleted?
The correct thing to do IMO, if you want to do this is not to replace rm, but to add, say "srm" and get into the habit of using that. That way, when it's not installed you instantly get alerted to the fact that you have no safety net by the:
phil@perdix:~$ srm
bash: srm: command not found
Then, if people want to train themselves to be shot in the foot, they're at liberty to alias rm to srm -i if they feel the need without damaging the system for other admins
Fil: you're right about the pre and postinst packages being unable to delete certain directories if safe-rm is protecting too many directories.
I thought about adding apt-get hooks, but then I figured that I really didn't want a buggy maintainer script to accidentally delete some of my "protected paths" anyways
Regarding the srm binary, I think it's a much better name than having to type safe-rm. Thanks for that suggestion.
I think that the whole point of the package is to be an opt-out one as opposed to opt-in however. I was logged in as a different user (and didn't have an alias set there) where I deleted half of my important files.
Good app really. I'll wait it for being more improved or even contribute someway.
I've seen already a deb package. What about adding it to mentors.debian.org?
lethalman: I'm not sure exactly what you mean by suggesting that this package be uploaded to mentors.debian.org because it's in unstable already and it's part of the collab-maint project.
So if you want to contribute anything, feel free to clone the git repo at http://git.debian.org/?p=collab-maint/safe-rm.git and send patches.
Everyone has his own safe-rm.
For me, this is enough to do it:
alias rm='echo -n "YOU ARE ON " && hostname && echo Sleeping for 2 seconds... && sleep 2 && rm -v'
It's more useful than the blacklist, actually; and if I know I really want to rm something, I \rm it.
http://svn.asheesh.org/svn/public/conf/bashrc.safe_rm is this snippet of my bashrc.
Another solution is to mount /usr read only. During normal operation you should never need write access anyway.
You can configure dpkg to remount /usr with write permissions before installing software, so you should never have to do it manually.
While you're at it, maybe (optionally) support the XDG Trash spec too - deleting would turn it into a move to Trash, compatible with Gnome/KDE, for easy undeletion.
Some people (not me) have been thinking about this too, see:
http://code.google.com/p/trash-cli/
and this thread:
http://lists.freedesktop.org/archives/xdg/2008-August/009792.html
I know it's non-standard but I tend to type:
rm /usr/lib/blah -rf
By putting the -rf at the end I ensure that I can't accidentally enter the command before I've typed the full path. I've also picked up the habit of always pausing before typing the final -rf to check that it is what I plan to do.
Regular expressions are not yet supported, but that's a great idea. I've added it to my issue tracker.
Since safe-rm is written in Perl, it shouldn't be too hard to implement either.