Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!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: <8902202358.AA00769@flamingo.LCS.MIT.EDU>
Date: 20 Feb 89 23:58:52 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 24


Thanks for your reply and the diagnosis of the problem.  I'm sorry
to hear there doesn't seem to be a clean fix to the problem.  

Actually, your suggestion to put a pause in reminds me that another
"problem" we've been having recently is that emacs seems to take 
an unreasonably long time already to save files.  It is certainly
much longer than it took, say, using Ultrix.  Maybe someone has already
stuffed a number of long pauses into the file-save code (but not enough
to catch all occurrences of this timing problem...)

I think the best fix, given the current kernel interface, is the following:

	-- when emacs detects (by means of its stats() information) that
	   a file has been ``changed'', it should actually go read the file
	   and see if it is actually any different than the buffer.  If 
	   the file and buffer contents are the same, then it should 
	   swallow its complaint and not bother the user with a spurious
	   notification that a change has occurred.  (I'd rather have a
	   little extra delay on writing than having to try to distinguish
	   real from spurious warning messages myself.)

Cheers,
	Ron Rivest