(was slashes, now NFS devices)

[Barry Margolin]

In article <1991Mar9.170841.4042 at panix.uucp> zink at 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."

It's state maintained *by the client* in the server's file system.  The
server doesn't create .nfsXXX files automatically, they are created by
clients when deleting files that they know they have open.  They aren't
created when the server or one client deletes a file opened by another
client.

The NFS client implementation I use has a related hack.  The file writing
model provided on Symbolics Lisp Machines is that modifications to a file
shouldn't be visible to other processes until the stream is closed; also,
the stream may be closed in "abort" mode, in which case the file should be
left unchanged.  This is implemented by writing to a file named #XXXX.nfsNN
(where XXXX is the actual file name, and NN is a number).  When the file is
closed in normal mode, a bunch of renames occur (they also implement file
version numbers this way, so the old file is renamed to XXXX.~NN~); when it
is closed in abort mode the #XXXX.nfsNN file is deleted.

In both these cases, games are played with names in order to make the
simple filesystem model that the NFS protocol makes available emulate the
model wanted by the client OSes.  They could also be emulated by copying
data, but this can be expensive.  For instance, deleting an open file could
be implemented by copying it to a local file system (if you've got one) or
swap space (if you've got enough), and redirecting file descriptors to the
copy; delayed writing could be done by directing the output to a local file
or virtual memory, and doing the real writing at close time (however, most
programmers expect close to be a relatively quick operation, and users can
be quite confused when a program takes a long time to exit).


--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar