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

[Dmitry Gutov]

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.