frelink: restoring deleted open or loop-mounted files in Linux

Has it ever happened to you that an important file has been deleted (by yours or someone else's mistake) but this file is still open by a process or loop-mounted somewhere?

In the "still open by a process" case, if the file is relatively small, as well as static or append only, you can use the well-known tricks of

cp /proc/<pid>/fd/<fd> /new/file/path

or

tail -c +0 -f /proc/<pid>/fd/<fd> > /new/file/path

to bring it back from the land of the "unlinked" by copying to someplace safe.

But what happens if the file is too big to copy or changes in a random fashion so that "tail -f" can not ensure that the copy will have the latest updates? Even worse, what happens if the file is loop-mounted in which case there is not even an fd to copy it from?

The most suitable solution in this case is probably to do the "undelete" process at VFS-level in the kernel. Such a solution has the potential of being compatible with all linux filesystems (since they all go through VFS).

The proposal to introduce a system call (flink) for this use-case seems to appear every now and then in LKML (e.g., this post) but every time it gets rejected for (pretty legitimate) security reasons.

Therefore, the only reasonable way to implement the functionality is probably via a loadable module + userspace tool.

frelink is a "proof-of-concept" implementation of how this process can work, from the viewpoint of the user. It has been based on the code from the fdlink project, an earlier effort in this area.

It should already be able to undelete both from /proc fd links and from loop devices, if your kernel is supported.

Unfortunately, especially for the loop mount case we currently have to use a very ugly hack (a jprobe if you are wondering) to get the necessary information. The code is also in a "pre-alpha" stage from a robustness perspective, with very little testing so far.

Nevertheless, it has already proved quite useful in some "extreme" cases in the last few days, so I thought it would be good to share it (you should read its big fat warning before using it of course).

Since the tool is now in the "it works" phase, what remains is to make it "work right" (making it fast is pretty much pointless in this case). This will probably require changes in the kernel infrastructure like e.g., in the loop module.

In the meantime, testing and comments will be happily accepted here or at my pktoss address at the mail service from google ;)

-Pantelis