bug#13149: 24.3.50; Emacs thinks file was changed outside Emacs, but it was not

[Paul Eggert <eggert@cs.ucla.edu>]

On 02/02/2013 01:38 AM, Eli Zaretskii wrote:
> My testing indicates that a file on NTFS has its time stamp changed in
> this scenario, while a file on FAT32 will not.

OK, thanks, then we need to check for that problem too.

Rather than go through a lengthy remote debugging session
with Drew, I'm inclined to disable the heuristic
on MS-Windows, as that should fix the problem once
and for all.  That is, we just live with the race conditions
on MS-Windows (which is what Emacs users have done for many years)
and fix the race conditions only on GNU and other systems
that support POSIX.1-2008 well.

I installed the following patch to try to do that, as trunk
bzr 111664.  If Drew continues to have the problem even with
this patch, we can investigate further by inserting some
logging code along the lines that we discussed.

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2013-02-02 17:14:24 +0000
+++ src/ChangeLog	2013-02-02 19:18:00 +0000
@@ -1,3 +1,14 @@
+2013-02-02  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Avoid file time stamp bug on MS-Windows (Bug#13149).
+	* fileio.c (Fwrite_region): Don't use the heuristic on empty files,
+	as FAT32 doesn't update time stamps when truncating them.
+	Also, check that a file time stamp is not a multiple of 100 ns;
+	this should catch all instances of the problem on MS-Windows,
+	as its native file system resolution is 100 ns or worse, and
+	checking for a non-multiple of 100 ns should impose only a small
+	overhead on systems with ns resolution.
+
 2013-02-02  Eli Zaretskii  <eliz@gnu.org>
 
 	Avoid encoding file names on MS-Windows when they need to be run

=== modified file 'src/fileio.c'
--- src/fileio.c	2013-02-02 17:14:24 +0000
+++ src/fileio.c	2013-02-02 19:18:00 +0000
@@ -5020,11 +5020,22 @@
 	  if (fstat (desc1, &st1) == 0
 	      && st.st_dev == st1.st_dev && st.st_ino == st1.st_ino)
 	    {
+	      /* Use the heuristic if it appears to be valid.  With neither
+		 O_EXCL nor O_TRUNC, if Emacs happened to write nothing to the
+		 file, the time stamp won't change.  Also, some non-POSIX
+		 systems don't update an empty file's time stamp when
+		 truncating it.  Finally, file systems with 100 ns or worse
+		 resolution sometimes seem to have bugs: on a system with ns
+		 resolution, checking ns % 100 incorrectly avoids the heuristic
+		 1% of the time, but the problem should be temporary as we will
+		 try again on the next time stamp.  */
+	      bool use_heuristic
+		= ((open_flags & (O_EXCL | O_TRUNC)) != 0
+		   && st.st_size != 0
+		   && EMACS_NSECS (modtime) % 100 != 0);
+
 	      EMACS_TIME modtime1 = get_stat_mtime (&st1);
-	      /* If neither O_EXCL nor O_TRUNC is used, and Emacs happened to
-		 write nothing to the file, the file's time stamp won't change
-		 so it should not be used in this heuristic.  */
-	      if ((open_flags & (O_EXCL | O_TRUNC)) != 0
+	      if (use_heuristic
 		  && EMACS_TIME_EQ (modtime, modtime1)
 		  && st.st_size == st1.st_size)
 		{