If there would be a way to create a hardlink to that inode you could really recover the file (lsof will show you the inode number).

Is there some arcane unix command that allows you to do that ?

If the file is large enough there may not be enough space to do a copy, so that's why it would be nicer to actually restore that inode...

jam@jam:~$ touch z

jam@jam:~$ tail -f z

^Z

[1]+ Stopped

jam@jam:~$ rm z

jam@jam:~$ lsof | grep /home/jam/z

tail 19192 jam 3r REG 8,17 0 821339 /home/jam/z (deleted)

jam@jam:~$

The 821339 is the inode.

In *BSD you can use fsdb to link an inode to a directory, ala:

    -# fsdb /dev/ufs/foo
    > inode 424242 # inode number of the target directory
    > ln 821339 myimportantfile

You might also need to do "inode 821339" and "uplink" to increment the link count. Alas, you can't do this on a live filesystem, at least not safely, and once deleted the inode will be cleared, so doing this won't get your file back. Maybe if you pull the plug and try it on an unclean filesystem?

Can you use 821339 as the target to ln? (Sadly I'm on Windows right now... work... and can't really experiment.)

i.e. -> ln 821339 new-file-name

no, unforunately not, I hoped for that too, but it seems that ln does not have any documented feature that would do that.

Effectively all ln does is call the 'link' system call, the paramters of 'link' are two path names on the same file system.

Could you not just hardlink to the /proc/<xxx>/fd/<y> file descriptor? I haven't tried this, but considering you can `cp` from the open descriptor to a new file, I should also think you could make a new hardlink to that same descriptor.

/proc is its own filesystem so its 'inodes' are incompatible with whatever FS your disk is on.

Good catch. My hardcore Unix-fu is still lacking in places... =\

whoops, sorry, on crack. You can't after it's been deleted.

It shouldn't be too hard to come up with a kernel extension that allows you to do this - in fact I wouldn't be surprised if there already was an undocumented ioctl() that links a particular inode on a file system.

Alternatively, the sledgehammer method is hitting the power button: a fsck should be able to pick up the nonzero refcount and make it available in lost+found. (depending on the file system)

I've often wondered if there's a user-visible way of doing that. (the file only disappears after the refcount hits 0 after all) Great find!

this works on pretty much all unixes and recently saved my team's ass after a 3am finger fumble that unlinked a very important 500g file.

Last time I used them, none of the following Unixes had a /proc filesystem: FreeBSD, NetBSD, IRIX, AIX, Ultrix, SunOS 4, MacOS X, NeXTStep. The only Unixes I do know of that have it are Solaris (SunOS 5), Linux, and Plan 9, which isn't really Unix.

FreeBSD has a procfs, but it isn't mounted by default -- mostly due to its unofficial name (rootmefs).

Thanks! I didn't know.

Actually, I should elaborate slightly -- FreeBSD actually has two procfses, the real one (procfs) and the one which is used for linux binary compatibility (linprocfs). But neither of them is mounted by default.

The root of this "trick" is that rm does not delete the file it reduces its inode link count, until the inode link count goes to 0, the file is still on disk.

look up fsdb and friends.

Even after the inode link count is 0, if a process still has the file open, it still remains on disk; that's the root of this trick. However, that is not sufficient; you also need a way to get access to the file so you can copy the data out of it before the process closes it. That is the interesting part of this trick — a way to use the /proc filesystem to get at the file.

cp /proc/322/fd/3 savedfile is a lot easier than fiddling around with fsdb on a mounted filesystem.

copying the file from /proc creates a copy. fsdb allows you to map a name to an inode (er.. inode to a name). this is quite handy if the file is being written to. and fsdb is frequently available where proc is not.