bug#9256: Erroneous output from "verify-visited-file-modtime" (fileio.c)

[Vivien Mallet]

Dear Emacs developers,

In Emacs 23 and Emacs 24 (built sometime ago from Git repository),
"(verify-visited-file-modtime (current-buffer))" sometimes returns 'nil'
instead of 't'. This happens often, even if the file has not been
modified by another program.

One reason is that stat can return an EINTR error. I am running
Linux. According to the manpages, stat is not supposed to fail with
EINTR under a Posix system (contrary to SVr4), but this is what I
observe. I checked with a call to printf right after the error, and I
got errno == 4 which is EINTR here. After exposing this on IRC #emacs, I
was told it could be due to the NFS mount (with option "intr") as the
files are on a network NFS volume. Hence I modified fileio.c to call
stat again after an EINTR error is raised. I attach the patch. If it is
confirmed that stat can return EINTR, there might be other calls to stat
in Emacs that need the correction.

fileio.patch
Description: Text Data

This solved only part of the problem. I still get a lot of false 'nil'
from "(verify-visited-file-modtime (current-buffer))" because stat
returns ENOENT. One may argue this comes from my network, but the
problem appears only inside Emacs. I wrote a small program to call stat
a (huge) number of times on a regular basis (on a file previously opened
by the program), but I did not get a single error. Maybe the way Emacs
opens the files has something to do with that? I would be grateful to
you if you could suggest a few tests to find out why Emacs may
experience problems with stat while other programs do not seem to face
the issue at all (no EINTR, no ENOENT).

Note that, on this network, the problem is met by all Emacs users I
know, whatever their Emacs configuration. The computers are running
Linux 2.6.32-31-generic x86_64, under Ubuntu 10.10. The involved Emacs
versions are 23.1.1 (Ubuntu package) and 24 (git commit
78cda4761357774eb9daa19546a078f24aa1ee66 from 19 March 2011). I was told
the problem does not appear in Emacs 22, but I did not check it myself.

Thank you for the great work.

Best regards,
VM.