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.
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
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)