Xref: utzoo comp.unix.shell:2346 comp.protocols.nfs:2422
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!agate!darkstar!cats.ucsc.edu!jik
From: jik@cats.ucsc.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.shell,comp.protocols.nfs
Subject: Re: reading an unlinked file (was: cat, pipes, and filters)
Message-ID: <16703@darkstar.ucsc.edu>
Date: 6 Jun 91 04:31:08 GMT
Article-I.D.: darkstar.16703
References: <1991May31.165446.1530@progress.com> <10918@chorus.fr> <1991Jun04.224044.1971@am.sublink.org>
Sender: usenet@darkstar.ucsc.edu
Followup-To: comp.unix.shell
Organization: University of California, Santa Cruz
Lines: 20

In article <1991Jun04.224044.1971@am.sublink.org>, alex@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@CATS.UCSC.EDU