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

[Jonathan I. Kamens]

In article <1991Jun04.224044.1971 at am.sublink.org>, alex at am.sublink.org (Alex Martelli) writes:
|> 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...

Although the NFS protocol doesn't know anything about files that are open on
an NFS client and then unlinked, many (most?) NFS client kernel
implementations deal with this properly.  If you open a file on an NFS
filesystem and then unlink the file on the same machine, then client kernel
realizes what you're doing and doesn't really send then unlink NFS protocol
request to the NFS server.  Instead, it sends a rename address to change the
name of the file to something like .nfsXXXX (where XXXX is replaced by a
number) in the same directory, and then actually unlinks the file after the
processes that have opened it on the client have closed it.


-- 
Jonathan Kamens					jik at CATS.UCSC.EDU