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

[GNU bug Tracking System]

Your message dated Mon, 20 Jan 2020 01:36:24 -0800
with message-id <address@hidden>
and subject line Re: Erroneous output from "verify-visited-file-modtime" 
(fileio.c)
has caused the debbugs.gnu.org bug report #9256,
regarding Erroneous output from "verify-visited-file-modtime" (fileio.c)
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
9256: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9256
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: Erroneous output from "verify-visited-file-modtime" (fileio.c) Date: Sat, 06 Aug 2011 10:28:52 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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.

--- End Message ---

--- Begin Message --- Subject: Re: Erroneous output from "verify-visited-file-modtime" (fileio.c) Date: Mon, 20 Jan 2020 01:36:24 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

I'd expect things to bug out pretty regularly across the board,
since you'd have to check for EINTR in every single call to a bunch of
system calls

Yes in theory. However, Emacs already does the EINTR check for open, read and write even on regular files where POSIX says it can't happen (but it does happen with NFS). If you've recently dealt with an NFS file then it'll be cached on the client and you won't get EINTR, so in practice the issue comes up only for syscalls that are applied to a file that hasn't been looked at lately. stat is one of these calls (hence the bug report) so we might as well do the EINTR check for it as well. I installed the attached patch to do that for stat and similar calls, and also for openat (which I think was overlooked when 'open' was done).

The other part of this bug report (with ENOENT) is not something Emacs can work around and it's surely a bug in the Linux NFS client that was most likely fixed a while ago anyway <https://bugzilla.kernel.org/show_bug.cgi?id=14541>.

As I think both issues in the bug report have been addressed, I'm boldly 
closing it.

0001-Work-better-if-stat-etc.-are-interrupted.patch
Description: Text Data

--- End Message ---