On 16.01.2013 9:57, Paul Eggert wrote:
> On 01/15/2013 03:44 PM, Dmitry Gutov wrote:
>> Maybe it's a sign of my system slowly falling apart.
>
> It does sound like a fairly serious issue of some sort.
> I did think of a patch (attached) but I'd rather not
> apply it if the system in question is merely experimental,
> since it introduces a race even on non-buggy systems.

I've been using the virtual machine to code Ruby for some time now, and 
I intend to continue doing it. It is replaceable, though, since all the 
important stuff is backed up.

Thank you for the patch, it works perfectly on the file mounted over 
vboxsf (but regarding applying it, see (*)).

I just now recompiled emacs-24 (revno 111176) again (bzr revert; make 
clean; make bootstrap) on the Ubuntu machine, and it seems to work fine 
now. Also recompiled the trunk a few times. The "sloppy" patch now works 
fine as well, aside from the need to explicitly set the variable. "fstat 
and lstat mismatch" is still there, though, so it's probably unrelated.
No idea what the problem was with my tests last time, I'm blaming space 
rays.

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'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 tried to work around the whole thing by instead sharing the 
directory in Windows the usual way and mounting it over CIFS (the 
package cifs-utils in Ubuntu). Yet again, emacs-24 works fine as-is (on 
both virtual machines, in this use case), but the trunk (revno 111517) 
exhibits the same buggy behavior I've been writing about.

And the "sloppy" patch helps (when the var is set), but the last one 
doesn't. See the instrumented output for the usual scenario with the 
last patch applied, below.

Can anyone confirm this? Mounting stuff over CIFS/Samba should be a 
relatively common situation.

If this is indeed reproducible, I think we need this to work without 
requiring the user to customize a variable.

find-file
dired.c:958: stat_mtime=1358411932.626214300
dired.c:958: stat_mtime=1358411932.626214300
fileio.c:3586: stat_mtime=1358411932.626214300
lread.c:1228: stat_mtime=1358194311.328310000
lread.c:1228: stat_mtime=1358411625.122214750
lread.c:1228: stat_mtime=1358194311.328310000
lread.c:1228: stat_mtime=1358411580.742214813
modify
fileio.c:5414: stat_mtime=1358411932.626214300
save
fileio.c:5414: stat_mtime=1358411932.626214300
fileio.c:5414: stat_mtime=1358411932.626214300
fileio.c:5025: stat_mtime=1358412092.606214085
fileio.c:5042: stat_mtime=1358412092.606214085
fileio.c:5072: stat_mtime=1358412092.606214085
dired.c:958: stat_mtime=1358412092.606214085
dired.c:958: stat_mtime=1358412092.606214085
modify again
fileio.c:5414: stat_mtime=1358412092.606214000
lread.c:1228: stat_mtime=1358194311.328310000
lread.c:1228: stat_mtime=1358411328.034215171
y
save
fileio.c:5414: stat_mtime=1358412092.606214000
yes
fileio.c:5414: stat_mtime=1358412092.606214000
y
fileio.c:5025: stat_mtime=1358412142.122214017
fileio.c:5042: stat_mtime=1358412142.122214017
dired.c:958: stat_mtime=1358412142.122214017
dired.c:958: stat_mtime=1358412142.122214017

No zeros or "fstat and lstat disagree" messages here, although I applied 
that patch, too.