Where do files go when the rm command is issued?

Question

Recently I accidentally did rm on a set of files and it got me thinking where exactly these files end up?

That is to say, when working with a GUI, deleted files go to the Trash. What's the equivalent for rm and is there a way of undoing an rm command?

Answer 1

Nowhere, gone, vanished. Well, more specifically, the file gets unlinked. The data is still sitting there on disk, but the link to it is removed. It used to be possible to retrieve the data, but nowadays the metadata is cleared and nothings recoverable. There is no Trash can for rm, nor should there be. If you need a Trash can, you should use a higher-level interface. There is a command-line utility in trash-cli on Ubuntu, but most of the time GUI file managers like Nautilus or Dolphin are used to provide a standard Trash can. The Trash can is standard itself. Files trashed in Dolphin will be visible in the Trash from Nautilus. Files are usually moved to somewhere like ~/.local/share/Trash/files/ when trashed. The rm command on UNIX/Linux is comparable to del on DOS/Windows which also deletes and does not move files to the Recycle Bin. Another thing to realize is that moving a file across filesystems like to your USB disk from your hard disk drive is really a copy of the file data followed by unlinking the original file. You wouldn't want your Trash to be filled up with these extra copies.

Answer 2

For ext3/ext4, you can try recovering files using tools like extundelete or ext3grep, or even go messing with the low-level structures manually (not for the faint of heart); for many filesystems, you can try to search for the not-yet-overwritten blocks by certain patterns (e.g. magicrescue can search for JPEG headers, amongst other things). Note that these are using heuristics to recover the files from the metadata left behind, so full recovery is not guaranteed - it's more of a last-chance bet (as those require that some traces of the files remain in the journal, and that the blocks weren't overwritten yet).

So, for all intents and purposes, files removed with rm are gone - you could try such necromancy as these tools offer, but don't depend on it: these are the tools to try when everything else fails. Better dig out your latest backups (you have been making backups, right? Oh well, live and learn...).

Answer 3

Regarding undoing the effects of rm:

Given that most filesystems only remove the reference to the data and indicate that the blocks as free, you could try to locate your data reading directly from the device. With a bit of luck the blocks containing your file(s) haven't been claimed for something else.

This assumes you have something fairly unique to look for, that you have root on the system and I'm guessing piecing together anything that spans more than one filesysteme block (probably 4k) might end up quite laborious if the filesystem didn't manage to put the file(s) in contiguous blocks.

I have successfully recovered the contents of a couple of plain-text files by running strings on the device the filesystem was on, and using grep looking for something from those files with a large context (-C). (And shortly after that incident, the company decided to spend some resources on implementing backups)

Answer 4

Whenever you delete a file using rm command, the file's data is never deleted. In other words the blocks in the file system containing data is still there.

What happens is when you run the rm command, the system marks the inode belonging to that file as unused and the data blocks of that file also as unused (but not wiped out). However ext3 zeros most of the fields in the inode, when a file is deleted.

This normal marking of unused is done for the speed... Otherwise for deletion it will take some more time. That's why you might have noted deleting even large files are faster (you can recover the data if that data blocks are not overwritten).

More Info: Inode Structure, How file deletion works

Answer 5

Look also into ~/.snapshot if the file was recently removed.