Giorgos Keramidas, after reading an article about how rm -rf / (i.e. accidentally deleting your operating system) is avoided by Sun, suggested on the hackers@freebsd.org mailing list some changes to protect from that. An extensive discussion (bikeshed) ensued. See “Protection from the dreaded “rm -fr /” thread on the former link, if you are curious. It’s still not resolved.
On the other hand, this has been quickly fixed in DragonFly, without changing the basic function of rm. New installs will have this safer behavior by default, though the old unsafe setup can be restored if desired.
The -I change seems like a good fix, but Matt missed one of the better developments that came out of that discussion: create a new file flag that forbids recursive deletion of a directory.
chflags srunlink /etc, for example, would stop any attempt to recursively remove /etc, and could be set/unset locally. I’d suggest that by default, the flag should be applied to /; smart admins can apply it to /etc, /usr/local/etc/, etc. as they see fit.
although i think this is a good idea, i believe it would not be easy to implement, since the kernel doesn’t know when a recursive deletion is going on (you delete each file in a directory with unlink() and then rmdir() the empty directory).
but maybe i’m completely wrong :)
File flag(s) are checked when rm stats a file, which it does prior to deletion. rm knows about the flag and about recursive deletion, so it can make the choice there- no kernel involvement required.
but then it would work only for rm… if i tried to remove a directory using, say, a ruby script, the srunlink flag would be ignored and the deletion would work.
i did an rm accidently once:
i’ve been working for a long time and increased my speed of working as i wanted to go home.
…and a few seconds later, my /usr/local/etc directory was history.
the interesting part is:
the command was of course not:
rm -rf /usr/local/etc
(the -f is implied anyway on freebsd)
it was rather something like only:
rm -r etc
and i didn’t enter it myself, instead it was in my history after deleting a temporary etc directory somewhere else.
i quickly restored the directory from my last backup and didn’t think about it anymore…
but reading through your postings made me think about it once again:
in my opinion, any solution that is based on a confirmation has a reasonable weekness:
if you manage to accidently rm -rf /something, you will also manage to confirm your accident
and once you get used to a rm -r –f-even-more /something the whole mechanism is worth nothing.
my idea would be the following:
rm -rf /
> this is always stupid
rm -rf something
> operation not supported
rm -rf /absolute/path/to/something
> this is ok.
In the Book BSD Hacks (O’Reilly), Dru Lavigne explains a Hack for this making a Trash Directory and so solving this problem. I haven’t tried but seems to be interesting.