Difference between revisions of "Invisible files"

From CRIU
Jump to navigation Jump to search
(Created page with "In Linux files may be inaccessible for open() but still be present in the system. This can happen in several ways and this page is about how this can happen and what CRIU does...")
 
Line 9: Line 9:
 
</pre>
 
</pre>
 
After it the /foo/bar file will have its name removed from the filesystem tree (and from the on-disk data too), but since the file is still held by the process (this structure is explained in the article about [[dumping files]]), the blob with data itself is still there.
 
After it the /foo/bar file will have its name removed from the filesystem tree (and from the on-disk data too), but since the file is still held by the process (this structure is explained in the article about [[dumping files]]), the blob with data itself is still there.
 +
 +
In this scenario file there are two different sub-cases. First, is when the file's number of hard links is zero, i.e. the /foo/bar name was the last (or the only it ever had) one removed. Another situation is when the link count is not zero, which means, that some other name for this file exists (hard link). In the latter case it's important to notice, that Linux VFS layer generally does ''not'' allow to find out this other name. Sometimes it's possible, but typically it's not.
 +
 +
=== Virtual filesystems ===
 +
 +
For virtual filesystems like proc or sysfs there's another possibility for such files to appear. It's the removal of the object represented of a file on this FS. In particular, if we open some file in /proc/$pid and the respective task dies the path of the opened file would get removed, while the file itself would be still alive (though reporting ENOENT error on any attempts to read from one).

Revision as of 07:52, 3 December 2014

In Linux files may be inaccessible for open() but still be present in the system. This can happen in several ways and this page is about how this can happen and what CRIU does about it.

How file can lose it's path

This is pretty simple. A process may do this series of operations

int fd = open("/foo/bar");
unlink("/foo/bar");

After it the /foo/bar file will have its name removed from the filesystem tree (and from the on-disk data too), but since the file is still held by the process (this structure is explained in the article about dumping files), the blob with data itself is still there.

In this scenario file there are two different sub-cases. First, is when the file's number of hard links is zero, i.e. the /foo/bar name was the last (or the only it ever had) one removed. Another situation is when the link count is not zero, which means, that some other name for this file exists (hard link). In the latter case it's important to notice, that Linux VFS layer generally does not allow to find out this other name. Sometimes it's possible, but typically it's not.

Virtual filesystems

For virtual filesystems like proc or sysfs there's another possibility for such files to appear. It's the removal of the object represented of a file on this FS. In particular, if we open some file in /proc/$pid and the respective task dies the path of the opened file would get removed, while the file itself would be still alive (though reporting ENOENT error on any attempts to read from one).