Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ATHENA.MIT.EDU!jis
From: jis@ATHENA.MIT.EDU (Jeffrey I. Schiller)
Newsgroups: gnu.emacs.bug
Subject: Re: Emacs bug? (Gnu Emacs, Large Files (RMAIL) vs. NFS)
Message-ID: <8902222304.AA26039@OSIRIS.MIT.EDU>
Date: 22 Feb 89 23:04:01 GMT
References: <8902222127.AA11843@auspex.com>
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 43


   Date: Wed, 22 Feb 89 13:27:27 PST
   From: guy@auspex.com (Guy Harris)

   >	-- I open a file for output with NFS, and write to it.
   >	-- I close the file.
   >	-- I open the file and read from it.
   >Presumably, NFS will guarantee that the contents of the file I read are 
   >identical to what I wrote.

   Yes, but it does *not* necessarily do so by syncing all unwritten data
   to the server before doing the "read".  The unwritten data is stored
   somewhere on the NFS client; the "read" can just pick up that data
   rather than going to the server.

	Indeed that is what is happening, a read is going to the local
cache.

   >If NFS doesn't have this bug, then can't we use a dummy read operation
   >to more or less force NFS to finish writing and close the file so
   >stats() will work OK?

   Try doing an "fsync" before the "close", assuming your OS has "fsync"
   (SunOS and Ultrix should both have it); if "fsync" is implemented
   properly (as far as I know, it is so implemented in SunOS), it will not
   return until *all* unwritten data for the file descriptor handed to it
   has been sent to the server.  The SunOS version of "vi" does an "fsync"
   after writing out a file and before closing it.

	I believe Ron is using a Wisconsin port of the Sun NFS code.
Last time I looked at the source code for fsync, it only guarantees
that the writes have been queued (which only means that they are on
the "async_daemon" queue [the queues serviced by the /etc/biod
processes]) not that the i/o has in fact completed.

	An alternative to what I suggested in my last message might be
to change the comparison code in Emacs so that rather then requiring
the file modification date to exactly match the buffer modification
date, allow a certain small tolerance, proportional to file size. This
will eliminate an unnecessary pause and in effect provide the same
semantics.

			-Jeff