Re: Spurious "file has changed on disk" warnings on Linux
SL Baur writes:
Justin Vallon <vallon(a)mindspring.com> writes in
xemacs-beta(a)xemacs.org:
> On Fri, 6 Nov 1998, Kyle Jones wrote:
>> stat() is relatively expensive compared to fstat(). Also, it
>> is surprising (to me) that close() would fiddle with the file
>> modtime, given that close() does no implicit flushing of data.
> I seem to remember somewhere that NFS writes may be postponed until
> close().
This brings back bad memories of old flame wars. I don't think NFS
will do this, but I know AFS can raise errors on close. If Dejanews
has restored enough old netnews, there should be megabytes on this
topic in the old archives.
Certainly I don't want to touch off any flame wars, but the current
behaviour makes XEmacs basically unusable on Linux with NFS-mounted
filesystems. I did a bit of Dejanews searching but didn't come up
with anything relevant searching for "NFS", "modtime" or "changed
on
disk". Do you remember what was the upshot of the previous
discussions on this?
The simple-minded experiment of adding:
printf("st.st_mtime=%d, b->modtime=%d\n", st.st_mtime, b->modtime);
before line 3690 in fileio.c will show that in fact the buffer is
recording a stale modtime, but only when visiting a file on an NFS
filesystem. It's got to be fixed, one way or the other - either by
fixing autoconf and the s&m files so that fsync() gets done, or else
by doing close()/stat() rather than fstat()/close() and accepting the
added expense of the stat.