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

[Paul Eggert]

On 01/17/13 23:56, Eli Zaretskii wrote:
> Who said anything was actually written to the file?  You'd need
> 'fsync' to be sure, don't you?

That depends on what one means by "actually written".  :-)

POSIX says a 'write' must result in st_mtime being updated
some time before the file's time stamp is used (and 'fstat'
and 'stat' both count as uses).  It is not required that the
written data or the updated st_mtime physically be stored on
nonvolatile storage; if the system crashes, the updates might
get lost.]

Also, it's not required that st_mtime must be updated to the
exact time stamp of the write -- it can be updated to a later
time stamp, so long as the later time stamp comes before st_mtime's
first use.  But the point is that st_mtime must be updated
"in memory", so to speak, just as the file's data must get
updated "in memory", so that any uses of the file see the
new st_mtime and the new data that got written.

Here, we seem to have some cases where a write can occur
but st_mtime is not updated before the next stat or fstat.
I don't yet know how to characterize these cases, or how to
work around them.  Even Emacs's old approach (allow up to
1 second of slop) seems like it won't work in some cases
that have been reported here: over 2 seconds of slop in
<http://bugs.gnu.org/13149#115>, and over one minute of
slop in <http://bugs.gnu.org/13149##100>!

One approach that I've been toying with is that
Emacs could inspect the file system type, and if the file
system is known to be reliable (ext2, ufs, zfs, ...) we stick
with the new behavior in the trunk which uses fstat with no slop,
but otherwise we fall back on the Emacs-24 behavior, using stat
with 1 second of slop.  This won't allow the instances of
longer-than-1-second slops that we've seen reported here,
but maybe that's good enough.

I'm not particularly happy with this idea, but there is
a limit to what Emacs can do to work around filesystem bugs.