reading an unlinked file (was: cat, pipes, and filters)

[Brent Callaghan]

In article <1991Jun04.224044.1971 at am.sublink.org>, alex at am.sublink.org (Alex Martelli) writes:
> Normal Unix semantics, when a file is opened for reading (from the
> outer shell, via the '<' redirection) and then unlinked (by the rm),
> is that the file's directory entry is removed, but its contents are
> still available to the process reading it; when it's finally closed,
> assuming the link removed was the last one, its space will be reused.
> 
> If, however, $FILE stands in for a file remotely mounted in such a
> way that usual semantics are not necessarily preserved (I'm thinking
> of NFS), then I'm afraid you might lose it, if it's large enough not
> to have been entirely read at the moment it's rm'ed.  I can't test
> here at home, and I hope somebody will show why this is wrong, but...

NFS implementations preserve "last open" semantics for a single
client by renaming the file to an "obscure" name.  The file
will apparently be deleted from the directory, but its filehandle
will still be valid.  The shell script will run correctly on
NFS filesystems.

On the other hand; if you're using the file on on one client and it
gets removed by another client then you're SOL...

Aside: Unix shares "last open" file behavior with other OS's of its era.
Is there a compelling reason for this behavior ?  The most common
argument is that it allows a process to set up a temporary file
that will disappear itself if the process dies, though "last open" appears
to be a clumsy way to achieve this.
--

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 Email: brent at Eng.Sun.COM
			 phone: (415) 336 1051