Spurious "file has changed on disk" warnings on Linux
Running XEmacs "Pyrenean-pre6" running on a Linux machine, visiting
files NFS-mounted from a Linux server gives lots of spurious "file has
changed on disk" warnings.
I have been looking at fileio.c and found two different ways of fixing
this problem, but I'm not sure which one is the Right Way.
Fix #1: Cause HAVE_FSYNC to be #defined.
src/sysfile.h says:
#if !defined (USG) && !defined (WINDOWSNT)
# define HAVE_FSYNC
#endif
Since s/linux.h #defines USG, the result is that HAVE_FSYNC is not defined
and the fsync in write-region internal (at line 3331 in fileio.c) is
not being done.
Changing src/sysfile to read
#if defined (LINUX) || !defined (USG) && !defined(WINDOWSNT)
causes the fsync to be done, and makes the problem go away.
But shouldn't the check for HAVE_FSYNC be handled by configure?
Fix #2: Change order of close and stat
Beginning at line 3340 in fileio.c is the following block of code.
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
/* Spurious "file has changed on disk" warnings have been
observed on Suns as well.
It seems that `close' can change the modtime, under nfs.
(This has supposedly been fixed in Sunos 4,
but who knows about all the other machines with NFS?) */
/* On VMS and APOLLO, must do the stat after the close
since closing changes the modtime. */
/* As it does on Windows too - kkm */
#if !defined (WINDOWSNT) /* !defined (VMS) && !defined (APOLLO) */
fstat (desc, &st);
#endif
/* NFS can report a write failure now. */
if (close (desc) < 0)
{
failure = 1;
save_errno = errno;
}
/* Discard the close unwind-protect. Execute the one for
build_annotations (switches back to the original current buffer
as necessary). */
XCAR (desc_locative) = Qnil;
unbind_to (speccount, Qnil);
}
#if defined (WINDOWSNT) /* defined (VMS) || defined (APOLLO) */
stat ((char *) XSTRING_DATA (fn), &st);
#endif
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Changing the order of the close and stat, as is done for WINDOWSNT,
also eliminates the spurious warnings. (Why are the VMS and APOLLO
cases commented out?)
I will submit a patch for this problem to xemacs-patches, as soon as I
know which of these two fixes is the "right" one - should I be
fsync'ing, or should I be fstat'ing after the descriptor is closed?