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

[Eli Zaretskii]

> Date: Fri, 01 Feb 2013 13:05:38 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: 13149@debbugs.gnu.org, 'Dmitry Gutov' <dgutov@yandex.ru>
> 
> I stared at the code a bit and found an unlikely bug
> that would cause the reported symptoms.  The bug occurs if the
> first write-region to a buggy file system happens to be
> an append that appends nothing.  If this occurs, Emacs
> incorrectly concludes that the file system is not buggy,
> and later uses of write-region to that file system (assuming
> no other non-buggy file systems are used in the meantime)
> will behave in the bad way that Drew reported.
> 
> I installed a fix for this bug as trunk bzr 111656.
> I'd be surprised if this fixes Drew's bug though.

Me too, but who knows?

> Eli, does MS-Windows conform to POSIX by updating st_mtime when
> Emacs creates a file (open with O_CREAT on a file that didn't
> previous exist) or truncates a file (open with O_TRUNC
> on a file that previously existed)?

MS-Windows doesn't conform to Posix, period ;-)

It's hard to say something definitive here, especially since some of
this depends on the filesystem being used (Drew uses FAT32, most
others use NTFS).  I cannot find any documentation on this issue.  The
only thing that Windows promises in its docs is that st_mtime is
updated when the last file descriptor for the file is closed.  So the
time stamp might not be up to date by the time we look at it in
write-region, because we use 'fstat' there before closing the
descriptor we used for writing.  However, the code that determines
valid_timestamp_file_system right after that should catch any problems
caused by this, and update the buffer's modtime to the value actually
recorded in the filesystem.  Perhaps FAT32 (see below) should always
do this, i.e. we should disable the optimization of probing its time
stamp validity only once?

> For example, if Emacs uses O_TRUNC on a file that is already empty,
> does MS-Windows update the file's time stamp even though the file
> has not changed?

My testing indicates that a file on NTFS has its time stamp changed in
this scenario, while a file on FAT32 will not.  (I used a USB flash
device for this testing, as I have no other volume accessible to me
that is formatted as FAT32.)

However, when the file is closed, the time stamp does get updated on
FAT32 as well.  So the code which determines
valid_timestamp_file_system should have caught this as well.  And
anyway, Drew's use case involves a non-empty file, so this precise
scenario is not a problem there.  For a non-empty file, when it is
truncated by opening it with O_TRUNC, the file's size reflects
truncation on both NTFS and FAT32, at least on my XP system.