Re: Weird irreproducible error

[Dave Dodge <dododge@...>]

On Tue, Oct 09, 2007 at 08:19:47PM +0100, David Given wrote:
> This allows you to delete a file while someone else has it open; the inode
> remains valid until the last reference goes away, i.e. when the last user
> closes the file. Then the OS will quietly remove the inode from the disk and
> free up the space.

The catch is that if you don't understand how Unix file semantics
work, you can get into some confusing situations.

A classic example is someone naively trying to rotate the log file for
a server process by simply renaming and compressing the file manually
while the server is running.  If the server isn't _explicitly_
designed to detect and accomodate that, there's all sorts of ways it
can quietly go wrong.  For example if you rename the open log file the
server may keep writing to it even though it has a different name.  A
compressor creates a new file to holding the compressed copy and then
deletes the original, but the inode sticks around and now the server
is happily writing its logs to a deleted file.  Then after a while the
disk suddenly appears to be full and you can't figure out where the
space has gone, because the file consuming it doesn't have a name
anywhere in the directory tree.

Another one: just recently I had a disk fill up, and to make space I
frantically copied a couple gigabytes of data files to another drive
and then "deleted" them.  But the first disk still claimed to be full!
For a few minutes I was really worried I'd gotten some sort of
filesystem corruption.  Then I finally remembered that I'd hard-linked
the data files into another directory a couple weeks earlier, and of
course the space won't be reclaimed until _all_ of the names for the
files are removed.

That said, I'll take these strange corner cases over Windows' locking
design any day.

                                                  -Dave Dodge