Can a file be retrieved by its inode?

Question

I ran following commands in the order specified:

$ln a b
$ls -i a b
523669 a 523669 b
$rm -f a
$ls -i b
523669 b

I concluded from this test that the command rm actually removes only the filename (a in this test) instead of the file, as the inode still exists and could be retrieved through another filename (b).

My question is, if a file is hard linked to only one filename, when rm is executed to the file, is the real file (i.e., the inode) removed completely? And if not, can a file inode be retrieved without a filename and only through the inode?

Answer 1

If you try to open a file via its inode, this bypasses any directory traversal. The directory traversal is necessary to determine the permissions of the file and directories leading to it. Without a directory traversal, the kernel has no way to determine whether the calling process is allowed to access the file.

There was a proposed patch to the Linux kernel to allow creating a link to a file from a file descriptor. It was rejected because implementing this securely would have been extremely hard.

Under Linux (and probably on other unix variants for the same reason), you cannot create a link to a deleted file, so if a file no longer has a name, you can't re-add one.¹ You can open a deleted file by opening the magic links under /proc/$pid/fd/.

If a file no longer has any link and is no longer open, it no longer exists and the space formerly used by its data may be reclaimed at any time.

¹ _{You may be able to do this by twiddling the bytes directly in the filesystem in a filesystem-dependent way, for example with debugfs for ext2/ext3/ext4. This requires access to the device on which the filesystem is mounted (i.e. typically only root can attempt it). However, while debugfs can access a file by inode, this doesn't help if the file is deleted: the file will be truly deleted if the application closes it, and running debugfs in read-write mode on a mounted filesystem is a recipe for disaster.}

Answer 2

The 'ln' and 'rm' commands have worked exactly like this in every UNIX filesystem since the early 1970s. Mac OSX, BSD and Linux all inherit this original design.

By itself, a UNIX file has no name, only an inode number or inum. But you can only access it through an entry in a special "directory" file that associates a name with the inum in question; you can't specify the inum directly.

A directory is itself a file, so you must also access it through (another) directory and so on, through a series of directory names delimited by forward slashes (/) known as a "path name". A path starts in the "current working directory" of the process unless the name begins with a "/", in which case it starts with the file system root directory. E.g., if the path name contains no "/" characters, then it is expected to be an entry in the current directory.

A non-directory file can have any number of path names, known as "hard links", and it will continue to exist until all of its path names have been removed and the last process has closed the file. Then the file is actually deleted and its space marked as available for reuse. That is, you can creat() or open() a singly-linked file and then unlink() it so it no longer appears in the file system name space, but the file will continue to exist until you close it. This is useful for temporary scratch files that won't be read by any other program.

Although directories have inode numbers, most file systems disallow hard links to them; they can appear in only one other directory. (One unusual exception is the Mac OSX HFS+ file system; this lets Time Machine backups work.) You can still create "soft links" to directories (or any other file). A soft link resembles a directory entry except that it contains another path name rather than an inum.

Every UNIX file has an owner, group and access permissions. It is necessary but not sufficient that they let you open the file; you must also have at least execute permission for every directory in the pathname you use to refer to it. That's why there's no standard way to open a UNIX file by its inode number; that would bypass an important, widely used security mechanism.

But this doesn't explain why there can't be a standard way for a root (privileged) user to open a file by inode number, since permissions checking is bypassed anyway. This would be very useful for certain system management functions such as backups. To my knowledge, such mechanisms do exist, but they're all filesystem-specific; there is no general way to do it for any UNIX filesystem.

Answer 3

On Linux, debugfs, the interactive ext2/ext3/ext4 file system debugger provides a ln command which can take an inode number as filespec and create a new hard link to the corresponding file. In practice though, this requires that the unlinked file is kept open by a process, maintaining an open file descriptor in /proc/[pid]/fd/[n]. Attempting this is on a deleted file will most likely lead to file system corruption.

This is because in order to ensure that ext3 (and in extension ext4) can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks the inode as "deleted" and leaves the block pointers alone. Even so, as the file system needs to be mounted read-write in order to create the hard link, the blocks reserved for the deleted file might already have been reallocated.

Prior to kernel version 2.6.39 it used to be that the ln -L|--logical option introduced in GNU coreutils v8.0 could be used to recover an unlinked file via an open file descriptor in /proc/[pid]/fd/[n] if both the unlinked file and new hardlink resided on a tmpfs file system . This capability has since been disabled, due to, as Gilles pointed out, the security considerations involved in allowing hard link creation directly from a file descriptor.

Answer 4

The question can be taken theoretically (which can be achieved with debugfs) or pragmatically (emergency situation). In the latter case, I assume the intent is saving the day and restoring the file's content, possibly urgently (which is how I landed on this question, so I think it is still relevant and useful).

Since there's no kernel API, debugfs should not be run on a live file system because it manipulates the FS structure directly. Therefore to do it live, you have to get hold of another filename. Assuming the file is still open by some process (any process), one can reach for the ever convenient file descriptors in /proc:

$ lsof -F pf "$PWD/a" | sed 's/^p//' # find pid and file descriptor number of any process having the file open
$ pid=1234
$ ls -l /proc/$pid/fd/* | grep "$PWD/a" # find file descriptor number
$ fd=42
$ cat /proc/$pid/fd/$fd > "$PWD/a.restored" # read contents to a new filename

Tips:

• if you have a doubt about the right fd, you can run commands such as file on it
• if there's a process writing to the file, be sure to stop that process ASAP or you won't get the latest data. An (untested) trick might be to open the file read only through the fd with some other process (try tail -f < /proc/$pid/fd/$fd > /dev/null, exit the writing process so that it exits cleanly, and use the new process's fd.

Answer 5

debugfs has a cat command that takes an inode number and prints the data where the inode's addresses point to.

For example:

sudo debugfs -D -R 'cat <8>' /dev/sda3 > ext4_journal

writes the contents of the ext4 journal (which commonly has inode number 8 but no file name) to a file.

The angle brackets around the inode number are not a placeholder, cat expects them to be there.

The -D causes debugfs to bypass the buffer cache. Without this option, you might read stale data.