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?