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
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 is a symbolic link to
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.