If you've used Linux, you already know rm can be dangerous. Getting a newbie to run sudo rm -rf / is a cliché joke among geeks. Helpfully, GNU rm won't actually let you delete the root directory, but you can still get into trouble.
Recently, I was cleaning out an old system disk in order to use it as a backup disk. I had already copied some data onto it, so I didn't want to just wipe it out, so I explicitly deleted the directories I did not want:
I knew it was going to take a while to delete all the files, so I went back to working on the backup script. After a few minutes, something odd happened: any command I entered failed with No such file or directory. The rm process continued to run, since it had already been loaded into memory. When the most basic commands like ls and cp don't work, there's not much that can be done. I couldn't stop rm; I had detached from the screen session and screen couldn't start again. I had no choice. I pulled the plug.
Booting from a USB drive, I was relieved to find that the root drive had not been wiped. The only casualty was the /lib directory, which explains the error: The ELF interpreter, /lib/ld-linux-x86-64.so.2 was gone. I restored /lib from a recent backup, and everything was fine.
So, why was /lib singled out? The culprit was the extra slash on lib64/ — lib64 is a symbolic link to /lib. Normally, rm does not follow symbolic links when deleting recursively, but it does follow links to directories when resolving paths given on the command line; rm -rf lib64 means "delete the symbolic link lib64", while rm -rf lib64/ means "delete the directory lib64 points to".
Today's lesson has been brought to you by the letter "B", for backups. It doesn't matter how secure your box is, one typo on the command line can completely clean out your data.
