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