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: <8902202219.AA08344@OSIRIS.MIT.EDU>
Date: 20 Feb 89 22:19:12 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 29


	I have also run into this problem and tracked it down to an
interaction between the way GNU Emacs determines whether or not a file
has been modified, and the asynchronous nature of NFS.

	Basically when you write out a file with Emacs, it writes the
file, closes the file and then "stats" it to get its modification
time. With a local file system the modification time for the file is
stable after the close() routine completes. However with NFS the
close() routine can complete and return control to Emacs (which then
stats() the file for its modification time) while output to the NFS
file is still pending. Some amount of time later the output is done
being written to the file and the modification time stabilizes on a
value further in the future then when Emacs stat()'d it. This of
course later confuses Emacs into thinking that the file has been
changed since the last time it was written. This tends to happen more
often with large files, and RMAIL files do tend to be large (my RMAIL
file is currently at 1.5 Megabytes for example).

	Unfortunately I don't have a clean solution to this problem
(there isn't a way with the current interface to the kernel to
deterministically know when a file is done being written and thus its
modification time stable).  A kludge might be a add a pause between
the time the file is close()'d and the stat() is performed. The length
of time for this pause could be proportional to the size of the file
(so unnecessary delays aren't added when small files are written).  I
don't know what a good set of parameters for the pause would be.

			-Jeff