Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!cs@Eng.Sun.COM
From: cs@Eng.Sun.COM (Carl Smith)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS client has out-of-date files
Message-ID: <126470@sun.Eng.Sun.COM>
Date: 17 Oct 89 19:08:19 GMT
References: <205@jove.dec.com> <17787@bellcore.bellcore.com> <1967@convex.UUCP> <1989Oct6.203732.12847@acd4.UUCP> <125974@sun.Eng.Sun.COM> <1989Oct9.191726.23428@acd4.UUCP>
Sender: news@sun.Eng.Sun.COM
Distribution: na
Lines: 19

In article <205@jove.dec.com>, mogul@decwrl.dec.com (Jeffrey Mogul) writes:
...
> Since you seem to have control over the source of the program used
> by Process B, I think if you have it do an "fstat()" of the file
> after receiving the synchronization message and before calling "read()"
> on the file, this will force the NFS client code on machine B to
> check with the server.  This is not, as far as I can tell, an official
> feature of the NFS specification, but is rather the way that NFS is
> actually implemented (at least in the earlier reference ports).

	Oh, dear.  I do hope no one will begin to rely on characteristics
of some NFS implementations to guarantee the correct behavior of their
applications.  NFS runs on too many operating systems to make that a
pleasant experience.
	The ``noac'' mount option that Sun and others use is a bit heavy-
handed for this application.  It seems to me all that's needed is a cache
flush fcntl.

			Carl