Bring back deleted files with lsof (Linux.com)

Posted Nov 17, 2006 8:42 UTC (Fri) by pphaneuf (subscriber, #23480) [Link]

Note that you do not even need lsof. All you need to know is the PID of the process that has your file open, and ls -l /proc/PID/fd will tell you what you need to know.

Posted Nov 17, 2006 10:27 UTC (Fri) by hawk (subscriber, #3195) [Link]

Wouldn't it be better to use ln rather than cp to get the file back into the filesystem?

Posted Nov 17, 2006 15:43 UTC (Fri) by elicriffield (subscriber, #33738) [Link]

I'm sick of seeing the 1/2 true articles. There is so much crap published now, a lot of it from linux.com, the fox news of how-to articles.

linux.com please hire a fact checker, who understands Linux. While this contents of the article don't out right lie, the headline misleads.

"Bring back deleted files with lsof"

The headline should read "There's a chance you mite be able to bring back a file if you just deleted it and your still using it"

lsof (why do they call it lsof anyway) has nothing to do with it, other then "listing open files".

90% of people don't read the articles just the headlines.Sometime in the near future someones going to delete a file somewhere and call up there poor Linux admin and say "Can you bring back this file i just deleted" and when they get the answer of "Nope" They'll respond with "Well someone on linux.com said you could, and there experts, it's L I N X DOT C O M."

</RANT>

Eli Criffield
http://eli.criffield.net/

Posted Nov 17, 2006 19:49 UTC (Fri) by allenp (subscriber, #5654) [Link]

Shallow articles like this are disappointing. Sure, you can recover an
unlinked file if some process still has it open. That's a rare special case.
The general case of actually deleted files is much more interesting, and
the article didn't touch it.

I helped my brother recover from a "rm -rf *" accident on an ext3 filesystem
several years ago. The inodes and contents of the deleted files were all
still there and I was able to get them back. The trouble was that the
directory entries had been damaged such that it was not possible to connect
a name to an inode. I ended up using file(1) to categorize files, and used
the inode number as the filename. Ick!

In poking at this, I discovered that ext2 did not obliterate the directory
entries of deleted files. I tracked down the code involved in removing
directory entries and could see a slight difference between the ext2 and
ext3 versions. Through a binary search, I identified the kernel version
where the change was introduced in the ext3 code.

I asked about reverting back to the old behavior on the kernel hackers'
mailing list. I only got a couple responses. One (might have been from
Alan Cox himself) said basically, "Propose a fix, prove that it doesn't
break anything, and we'll consider it." This was completely reasonable,
but out of my reach timewise, so I dropped it.

An article digging into current filesystems at that depth would be
welcome.

Paul Allen

Posted Nov 18, 2006 18:50 UTC (Sat) by dreadnought (subscriber, #27222) [Link]

Disappointed lately in the articles found both at hotwoforge and linux.com for having novel and yes useful content but not content which lives up to their headlines.

Posted Nov 22, 2006 17:16 UTC (Wed) by h.j.thomassen (guest, #15232) [Link]

Some topics keep coming back over the years, and this is one I have seen too many times before. And always with the same basic misconception: if you can find the block numbers where the "removed" file used to live, you can reconstruct the directory entry and the i-node, and (...cloud of green smoke here...) your file is brought back to life.

Wrong!

The case is true if some process still has the file open. Previous posters have correctly pointed out that this is a special case of the remove-recovery, and it is the *only* solvable one.

If you have removed a file, and no process still has it open, there is a huge difference between a PC (personal!!) operating system, and a real, multi-tasking (and multi-user) system as UNIX/Linux is.

If you live alone in your (personal) house, and you get up from one chair, and sit down on another, the first chair will stay unused.
If you sit on a chair in a room that you share with many others (such as an airport lounge) and you get up from your chair, how long will that chair stay unused?

The same holds for the disk blocks where your "removed" file used to sit on! Even if you manage to find out which collection of blocks your file used to sit on, how are your chances that all those blocks are still unused when you come back at a later moment? Greater than 0%, but definitely smaller than 100%. If you have a busy system your chances shrink in time. If your file had a large collection of blocks, your chances to find them all unused shrinks in time. etc.

So the entire discussion of this thread may be useful for people who are able to flip the power off switch of their computer right after they realise that they typed their "rm" erroneously. But please do not consider this to be some useful facility for Linux systems in general...
Linux is not for P(ersonal)C's only!

Hendrik-Jan Thomassen