Recovering deleted files using only grep

I seem to remember having a problem where I'd rm-ed a file I needed and using lsof to find the file handle and then being able to cat the data in to a new file using the handle instead of the filename? Details pretty fuzzy, sorry.

Edit:

Example of recovery this way, tested now, works for me - http://pastebin.com/c2djEcqr - the crucial part that I was forgetting is that there needs to be a file handle somewhere that's still open, which is probably not true in most cases. Worth a quick check before unmounting.

I've used ddrescue and photorec for these sort of "issues" before with much success.

My editor was still open, and the gocode code-completion daemon too. I looked up some way to dump a process's memory from StackOverflow and used it. (I used a Python script[1], but I see gdb's gcore command and other ways recommended elsewhere.) It worked out. An extra complication was that my home directory is encrypted, so searching the raw disk was out.

So: never too early to use version control. Also, if you think you even might have fat-fingered something, think a second before you do anything that could make the situation worse. I didn't pay enough attention to the error message that could have told me I'd messed up, and answered 'yes' to my editor asking if I should close the file, thinking it had just moved--if I hadn't done that it'd've saved a lot of time. On the other hand, had I kept on charging forth once I realized I had messed up, I could've easily closed the editor, ending the gocode process I wound up recovering stuff from.

So, yeah: be smarter than I was, y'all.

[1] http://unix.stackexchange.com/questions/6267/how-to-re-load-...

The extent to which new calls to deleted files are made will have a strong impact on this.

You can simply copy the (proc) file to a new location to recover it.

Remember: open files keep the contents present on disk until the controlling process exists or closes the filehandle.

Since you're actually accessing the file on disk your issues of storage contingency don't come into play -- it's all read back to you in proper file order.

But yes, files (and virtual files) on Linux are pretty slick.

I also remember being really excited learning about disk image files and the ways in which they can be manipulated. Including the options of creating filesystems on virtual disks, partitioning them, and them mounting those partitions, etc. First tried with bootable floppy distros, but I've played around with them in a bunch of contexts since.

When you delete a file on a mechanical hard drive the physical contents of the file still exist on disk, so you can use tricks like these to recover deleted data.

When the drive is then told to write over these locations it doesn't matter that there is old data there and it writes the new data to the location.

SSDs however store data in pages, and while they can write directly to an empty page they can not write directly to a page that already has data in it. Instead, an SSD has to read the current data from the page, modify that data with the new data that it wants to be there, and write the new data to the whole page at once. This is called a read-modify-write operation and is a major reason why SSDs (even now) decrease in performance as they fill up.

The issue is that when you delete a file on disk there is no way for the SSD to know that those data blocks aren't important anymore (without TRIM). The controller of the SSD has to manage a full drive of data (even if you're only actually using some percent of it) and only figures out that a file was deleted when it is finally told to write something else to that location.

TRIM tells the SSD that a file was removed and allows a controller to recover that area to help maintain its performance.

There is a really good discussion of this topic in this article from way back in 2009: http://www.anandtech.com/show/2829