2,257
edits
Changes
Jump to navigation
Jump to search
Line 9:
Line 9: + + + + + +
no edit summary
</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).