Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.internals
Subject: Re: (was slashes, now NFS devices)
Message-ID: <1991Mar11.001244.28792@athena.mit.edu>
Date: 11 Mar 91 00:12:44 GMT
References: <1991Mar9.170841.4042@panix.uucp>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 19

In article <1991Mar9.170841.4042@panix.uucp>, zink@panix.uucp (David Zink) writes:
|> P.S.  If NFS need hold no state on the server, what is a .nfsXXX file?
|> "I know, I know, it's not part of the protocol."

  The server has no idea that the .nfsXXX file represents a file that was
unlinked while open on a client.  The client kernel on the machine that did
the unlinking is the only thing that knows that.  So it's the client kernel
that contains the state in this case, not the server.  As far as the server is
concerned, the .nfsXXX is no more special than any other file.

  I'm not siding one way or the other in this discussion, I'm just pointing
out that (as far as I can tell) the whole .nfsXXX kludge does not show any
keeping of state per se on the NFS server.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710