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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Vivien Mallet <Vivien.Mallet <at> inria.fr>
Subject: bug#9256: closed (Re: Erroneous output from "verify-visited-file-modtime"
 (fileio.c))
Date: Mon, 20 Jan 2020 09:37:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 9256 <at> debbugs.gnu.org.

-- 
9256: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9256
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Vivien Mallet <Vivien.Mallet <at> inria.fr>, 9256-done <at> debbugs.gnu.org
Subject: Re: Erroneous output from "verify-visited-file-modtime" (fileio.c)
Date: Mon, 20 Jan 2020 01:36:24 -0800

[Message part 3 (text/plain, inline)]

> 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 (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Vivien Mallet <Vivien.Mallet <at> inria.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: Erroneous output from "verify-visited-file-modtime" (fileio.c)
Date: Sat, 06 Aug 2011 10:28:52 +0200

[Message part 6 (text/plain, inline)]

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 (text/x-diff, attachment)]

[Message part 8 (text/plain, inline)]

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.