Recovering Deleted Files through open fd's

oops, you deleted a file you've just downloaded thru a p2p file sharing app.

Maybe there's still a chance getting your data back without using your forensics kit.

Unix never releases the data blocks that are linked to a file, if a file descriptor to that file is still open. Hmmm, maybe if this p2p app is still running, we can get our file back, no?

p2p apps tend to have many file descriptors open since they're constantly sharing files to other peers. There's a good chance a file descriptor might still be open for the file you're missing. Linux gives you access to the file descriptor <n> of a process with pid <pid> thru /proc/<pid>/fd/<n>. This file looks like a symlink pointing to the pathname of the (long-lost?) file. Using open() on this file will not dup() the process fd [1] but will instead give you a new file descriptor pointing to the start of the relevant file. The following example illustrates this basic principle.

xx@yyy:/proc/1952/fd$ ls -al
total 0
dr-x------ 2 xx users 0 Feb 2 03:33 .
dr-xr-xr-x 4 xx users 0 Feb 2 03:33 ..
lrwx------ 1 xx users 64 Feb 2 03:34 0 -> /dev/null
lrwx------ 1 xx users 64 Feb 2 03:34 1 -> /dev/null
lrwx------ 1 xx users 64 Feb 2 03:33 2 -> /dev/null
lrwx------ 1 xx users 64 Feb 2 03:34 3 -> /tmp/foo (deleted)
lr-x------ 1 xx users 64 Feb 2 03:34 4 -> /var/lib/somefile
lr-x------ 1 xx users 64 Feb 2 03:34 6 -> /var/lib/some-other-file
xx@yyy:/proc/1952/fd$ dd if=3 of=/tmp/bar
0+1 records in
0+1 records out
175 bytes (175 B) copied, 0.000441111 seconds, 397 kB/s

In case you're wondering, the '(deleted)' flag comes from the fact that the particular dentry does not have a corresponding hash entry in the dcache. For more details, see fs/dcache.c and include/linux/dcache.h in your kernel sources.

So, now you got one more reason to share your files :-)

[1] Am I the only one that found this the logical thing to do? :p

You must be kidding me.. Part 1

from the manpage of diskseekd (1):

Several people have noticed that Linux has a bad tendency of killing floppy drives. These failures remained completely mysterious, until somebody noticed that they were due to huge layers of dust accumulating in the floppy drives. This cannot happen under Messy Dos, because this excuse for an operating system is so unstable that it crashes roughly every 20 minutes (actually less if you are running Windows). When rebooting, the BIOS seeks the drive, and by doing this, it shakes the dust out of the drive mechanism. diskseekd simulates this effect by seeking the drive periodically. If it is called as diskseek, the drive is seeked only once.

Shooting Super-16mm On A Low Budget

Excellent intro to shooting on 16mm. Covers minimum costs for a short production.