Hello,

A colleague of mine insist on running rm -rf when he deletes at least a file (does not even have any directories). He said a redhat tech support told him that the -rf will permanently delete the file from the system. I don't see it in any manpage.

I know -r is recursive and -f is force and include directories to be deleted. are inodes affected?

Your details on the options are correct. Rm takes what is given, rm -rf takes out the directory tree specified (i.e. the files, dirs, links & everything under them)matching the file spec.
What's available after an 'rm' command depends on the filesystem; vfat is recoverable, but ext4 filesystems have pretty poor recovery tools, and it's best to see deletion as permanent.

1 members found this post helpful.

rm alone will not remove directories and rmdir alone will not remove non-empty directories. These commands on their own are the safe ones to use in your everyday life. The "-r" argument is used with rm when removing directories recursively. Some people use "rm -rf" so that no error messages are reported and everything is effectively removed.

But, generally it is considered dangerous to use "rm -rf" all the time. You might be using the command without thinking, and if ever this command is run as root on an inappropriate file/directory, it will be a catastrophe. As business kid said, it is extremely rare to be able to recover from "rm -rf" if it was used incorrectly.

So, stick to rm and rmdir. Only add arguments when you need them.

1 members found this post helpful.

I once ran rm -f without escaping a leading space followed by a wildcard character and it removed every file in the directory. There are no good Linux undelete tools, but foremost is a file carver that can recover files from Linux file systems. The only thing is it doesn't preserve the filenames and it recovers every deleted file it can find. So, finding the file you wanted to recover can be a chore.

Me too. su'd to root, ran rm -f <paste>* - except the paste (right mouse click) didn't happen (sticky mouse button), so rm'd all files in /root/*
Fortunately, I had a daily backup to go to, but still...
I now am happy to answer "y" to each file to be removed ('cause alias rm='rm -i') rather than scramble to recover from a fat-finger issue.

Agreeing with others, don't use -r or -f routinely.

I feel it's a very bad choice to generalize this type of command. Instead, pay attention to what you're doing when you issue a rm command. The explanation as attributed to a tech support person is incorrect.

If a file is going to be deleted, it doesn't matter whether you used -rf or not, rm will delete it the same way with the same permanence. The -f flag keeps rm from prompting you if it has any questions, and the -r flag means it recursively deletes directories in addition to files, instead of just files. That's it. I don't know what he means by permanently deleting a file, as opposed to just deleting it. rm never uses any kind of "recycle bin" style setup, it will delete the file, but it could still be recovered off of the filesystem using a recovery tool. If you want to delete the file in a way that will prevent recovery, you need to use a completely different tool, such as shred.

I see that none of us actually answered the only question you asked...

Yes. inodes are affected. In fact, inodes are all that's affected by the rm command...it simply removes the inode to effect a "file deletion" -- no inode, no file.

No, "rm" does not directly remove or clear the inode. All it does is remove the link from the directory, and that causes the link count in the inode to be decremented by 1. When the link count becomes zero and the file is not in use by any process, the kernel will then mark the inode as deleted and release any storage space claimed by that inode. The rm command issues the unlink() call. That is all.

1 members found this post helpful.

Point taken. I mis-read the reference I was looking at (and which I can't find again). I thought it said inodes were "created" and "deleted".

To your "not in use" point: I have experienced situations where someone rm'd a file as it was being created by a long-running process without affecting the process at all. It merrily continued to write to the file even though it could no longer be seen by ls, and its log indicated successful completion, but, of course, the file was gone and the job had to be re-run.

Still, the short answer to the OPs question is yes, even if I mis-explained it. Thanks for straightening us out.

If you delete an open file, but the process that opened it is still running, you can recover the file from that process's entry directory in /proc, which is named after the PID. The file still exists in memory. You just have to copy it back to disk.

One of the great wonders of virtual file systems ...

2 members found this post helpful.

Good to know. Unfortunately we didn't know about the rm until after the process had completed. One of the hazards of several developers on a single dev machine. Needless to say, we didn't have access/authority to do those kinds of things in production. <sigh>