Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: (was slashes, now NFS devices)
Message-ID: <16413:Mar1201:02:3691@kramden.acf.nyu.edu>
Date: 12 Mar 91 01:02:36 GMT
References: <1991Mar9.170841.4042@panix.uucp> <1991Mar11.001343.15630@Think.COM>
Organization: IR
Lines: 19

In article <1991Mar11.001343.15630@Think.COM> barmar@think.com (Barry Margolin) writes:
> 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."
> It's state maintained *by the client* in the server's file system.

See, this is just an implementation technique. When people complained
that unlink() failed over NFS, this supposed ``statelessness'' didn't
stop Sun from (partially) fixing the bug. Similarly for any other bit of
filesystem semantics.

I don't mind people pointing out that inside NFS the client keeps some
of the filesystem state; that's a perfectly fine implementation
strategy, and it's easier to start with such an implementation if you
want reliability through crashes. I do mind people who look at this
``statelessness'' and use it as an excuse for incorrect semantics.

---Dan
A stateless filesystem is a useless filesystem.