Files, unliking, access, oh my.

[Ben Scott]

On Tue, Feb 19, 2013 at 2:40 PM, Ken D'Ambrosio <ken at jots.org> wrote:
> If process A is reading from a file, and process B deletes it, process
> A can continue to read from it until... well, until it stops reading
> from it.

  It can also seek it, write to it, etc.  This condition persists
until the process calls close(2) on the file descriptor.

  Some processes do this deliberately for temporary files: They
create/open a new file and then immediately unlink it.  This yields an
"anonymous file", which won't need to be specially cleaned up, even if
the program crashes.

  Remember, in *nix, one doesn't really delete files (inodes).  One
unlinks directory entries.  The kernel deletes files once all
references are gone.

  One of the things fsck does is check for inodes with a zero actual
reference count, and link them in "lost+found" by inode number.

  This is also why a cleanup routine is run for journaled ext3+
filesystems which weren't unmounted cleanly.  Even though the journal
should maintain metadata consistency, if such files were open when the
system crashed, they need to be found and cleared.

> Can that space that the file takes up be overwritten during
> this interim?  Or does the OS hold the inode sacrosanct until both
> references AND processes are no longer making use of it?

  The later.  The inode remains allocated until no longer referenced
by any directory or process.

  This can lead to situations where the free space in a filesystem is
less than one would expect by walking the filesystem to total space
allocated to named files, and subtracting that from the total space in
the filesystem.

-- Ben