Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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?
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 nothing's 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 1) a copy of the file data followed by 2) unlinking the original file. You wouldn't want your Trash to be filled up with these extra copies.
libtrash to change the behavior of rm. Lots of scripts use rm to clean up files and you don't want those showing up in Trash. I recommend using a dedicated command like trash from the trash-cli package. @pedro I should add that I once created a file * in my home directory. I had accidentally quoted * when I shouldn't creating it so I decided to remove it with with rm * natually. When I realized what I did I quickly killed the command, but it had already deleted a number of files in my home directory.
Apr 8, 2011 at 5:13
cp, and mv, to cp -i and mv -i when running as root. This changes the default behavior so those commands will always ask before overwriting existing files. Some sysadmins recommended to specifically remove those aliases so you don't end up expecting that behavior which may end up being lethal when on another system that follow default behavior.
Apr 8, 2011 at 8:13
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...).
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 file system block (probably 4k) might end up quite laborious if the file system 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 file system 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)
magicrescue that try to find images or sounds by their distinctive patterns.
Apr 8, 2011 at 20:48
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
chattr +s ("shred") attribute. It tells the filesystem to specifically overwrite this file with zeroes on deletion. Only some filesystems will support that attribute.
In Unix-style filesystems (including on Linux), files are not really "at" any particular place. Instead, the system uses hardlinks to point into pieces of what amounts to a big blob of data. So when you create a file, you also create its first hardlink: the one which actually resides at the place where you "saved" the file. If you make more hardlinks, then as far as the system knows, the file actually exists in several places at once.
When you "delete" a file, normally you're actually only deleting the hardlink that existed at the place you specified. This is why the system call to delete files is called unlink(). The system won't actually delete the file until there are no hardlinks left to it. But once that last hardlink is destroyed, so is the data.
So, where do files you delete go? If there are still hardlinks, they files are wherever the hardlinks you didn't delete are. If there are no hardlinks left, the files are gone.
Look also into ~/.snapshot if the file was recently removed.
