8

Is there a way to create a file in Linux that link to a specific iNode? Take this scenario: There is a file that is in course of writing (a log maybe) and the specific file is deleted but a link in the dir /proc is still pointing at it. In this case we need not a bare copy of it but an hard link to it so we can have the future modifications and the most last modification before the process close and the system delete it.

If we have the iNode number is there a way to achieve this goal?

Improve this question

3 Answers 3

Reset to default
16

Since there is no Syscall that involves iNode, because is a concept of extX fs and is not a good practice make a stove pipe but it is to make a chain of responsability (as M.E.L. suggests), there is only a NO answer for this question because at VFS level we handle files path and names and not other internal representations.

BUT to achieve the goal to track the most last modification we can use a continous monitoring and duplication with tail:

tail -c+1 -f --pid=PID /proc/PID/fd/FD > /path/to/the/copy

where PID is the pid of the process that have the deleted file still opened and FD is its file descriptor number. With -f tail open and hold the file to display further modification, with -c+1 start to "tail" from the first byte and with --pid=PID tail is informed to exit when the pid exit.

Improve this answer
1
  • inodes are not specific to ext2/3/4. They're part of the POSIX spec for how system calls like stat(2) work, and how you find hardlinks. But unfortunately you're right that there doesn't seem to be any way to make a link from /proc/PID/fd/FD to a real file, just open it for read/write. If only there was a system call like link(2) that took an open file descriptor as the source, rather than a path.
    – Peter Cordes
    Commented Dec 8, 2014 at 1:17
6

You can use lsof to recover deleted files (sometimes)...

> lsof | grep testing.txt
less    4607    juliet  4r  REG 254,4   21  
       8880214 /home/juliet/testing.txt (deleted)

Be sure to read the original article for full details before attempting this, unless you're a Maveric like me.

> ls -l /proc/4607/fd/4
lr-x------ 1 juliet juliet 64 Apr  7 03:19 
         /proc/4607/fd/4 -> /home/juliet/testing.txt (deleted)
> cp /proc/4607/fd/4 testing.txt.bk

http://www.linuxplanet.com/linuxplanet/tips/6767/1

Enjoy

Improve this answer
1
  • 1
    Gasp. You're right. I thought I just tested that, and it didn't work. NTL: The OP asked for a hard link, specifically not a copy.
    – M.E.L.
    Commented Aug 12, 2013 at 22:33
4

It's always difficult to answer a question like "can I do" confidently in the negative. But as far as I see, neither /sys/ nor /proc provide a mapping of open files descriptors that are not symlinks. I assume by "BUT a link in the dir /proc is still pointing at it" you mean that the /proc//fd/ entries look like symlinks? I'm almost sure you cannot recover the original file.

I take that back: As user user2676075 pointed out, copying does work. Just hardlinking doesn't ...

UPDATE: If you think about it, it's quite logical.

  • /proc and /sys are file systems different from your hard disk. So they can't provide file like directory entries which one could hardlink to a destination on the hard disk.

  • The /proc/*/fd/ entries pretend to be symlinks, but actually they are different, else the copying would not work. I think they pretend to be symlinks to provide meaningful information with 'ln -l'.

  • Regarding the (missing) capability to hardlink to some inode (let's say with some system call): This cannot be part of the kernel or the VFS-Interface, for the following reasons:

    • It would violate the integrity of the file system. The filesystem is not supposed to keep the disk blocks of files that are completely deleted around in the same manner as files that persist.

    • The inodes might be a completely virtual concept to identify a "slot where a datastream is stored'. I assume there can be implementations that would have a problem converting a slot that has no reference back to a slot which is refered to by a name in the file system.

    I admit the case against the possibility of such a system call is not water tight. But given the current state of the VFS interface (which AFAIR doesn't provide for such a call), it would be a heavy burden for any file system implementation (including e.g. distributed file systems) to provide a call to link a file into a directory by inode.

ATM I wonder if calling fstat before and after deleting the last reference is actually requires to return the same inode information ... t

Improve this answer
1
  • 1
    The reason hardlink-to-inode doesn't exist is that it would let people access files they shouldn't. A 700 directory makes everything under it private, unless you can bypass it with an inode number as an argument to link(2). What would be nice for this situation is link(2) taking an open file descriptor. Although even that would open up new things processes could do, if started with an open fd on a no-longer-accessible file, or one you couldn't open by yourself. Also, the deletion semantics are: disk space lives until last link AND last open fd AND last mmap disappear.
    – Peter Cordes
    Commented Dec 8, 2014 at 1:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.