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

[Dmitry Gutov <raaahh@gmail.com>]

On 17.01.2013 21:05, Eli Zaretskii wrote:
>> Date: Thu, 17 Jan 2013 14:32:56 +0400
>> From: Dmitry Gutov <raaahh@gmail.com>
>> CC: 13149@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>>
>> Looked at the VirtualBox bug reports, found just this one:
>> https://www.virtualbox.org/ticket/10986, not much information there.
>>
>> Some more about space rays:
>> 1) I now have a version of Emacs compiled on a brand-new Fedora virtual
>> machine from emacs-24 branch (revno 111185) that exhibits the problem.
>> Just tested it simultaneously with Ubuntu, emacs-24 on Fedora is buggy,
>> Ubuntu's is not. The following items (2 and 3) are from a few hours ago,
>> when I tested Fedora machine exclusively.
>> 2) Editing the file on a different disk on the host system (HDD vs SSD)
>> makes no difference, the bug is present.
>> 3) Process Monitor doesn't show any other processes accessing the file
>> on the host machine other than VirtualBox.exe, SYSTEM and
>> SearchProtocolHost.exe. The last one goes away if I stop the Windows
>> Search service, but the problem stays.
>
> I suspect that what you see is some bad interaction between VirtualBox
> and the nasty way Windows disk cache optimizes its disk I/O.  It is
> known to update the file attributes lazily, so data could be written
> to a file without the file's directory entry updated at the same time,
> until some time later.

I wonder why I don't see that with the straight Windows build editing 
files on the local filesystem. Does it forcibly disable some optimizations?

>> I'm attaching the exported event log for the open-modify-save
>> scenario (file-access-log.csv) in case someone knowledgeable can see
>> anything weird there (Eli?).
>
> I don't see anything interesting there, although I cannot pretend that
> I've studied every single entry.

Oh well. It was worth a try.