Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!THEORY.LCS.MIT.EDU!rivest
From: rivest@THEORY.LCS.MIT.EDU
Newsgroups: gnu.emacs.bug
Subject: Emacs bug? (Gnu Emacs, Large Files (RMAIL) vs. NFS)
Message-ID: <8902211751.AA01191@flamingo.LCS.MIT.EDU>
Date: 21 Feb 89 17:51:50 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 23


Jeff --

Regarding your explanation of the NFS/Emacs bug we discussed, wherein
emacs stats() the file before NFS is done getting it all written onto the
remote server, causing a spurious warning from emacs that the file has
changed on disk:

It seems to me that either the problem ought to be easily fixable, or else
the problem is more serious than I thought.  Consider the following 
scenario:
	-- 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.  That is, NFS should not have the bug that the
read operation can get inaccurate data because the write is not yet finished.
If NFS has this bug, then things are worse than I thought.  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?

	Thanks,
	Ron