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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9256 in the body.
You can then email your comments to 9256 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 1 (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 3 (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.

Message #10 received at 9256 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Vivien Mallet <Vivien.Mallet <at> inria.fr>
Cc: 9256 <at> debbugs.gnu.org
Subject: Re: bug#9256: Erroneous output from "verify-visited-file-modtime"
 (fileio.c)
Date: Sat, 23 Nov 2019 14:44:04 +0100

Vivien Mallet <Vivien.Mallet <at> inria.fr> writes:

> 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.

(There was unfortunately no response to this bug report when it was
reported eight years ago.)

Hm.  I'm not sure you can expect things to work with a setup like that,
really: 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, and basically do what you do here everywhere:

>    filename = ENCODE_FILE (BVAR (b, filename));
 
> -  if (stat (SSDATA (filename), &st) < 0)
> +  while ((stat_status = stat (SSDATA (filename), &st)) < 0 && errno == EINTR);
> +
> +  /* if (stat (SSDATA (filename), &st) < 0) */
> +  if (stat_status < 0)

> 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.

Indeed.  Does anybody have an opinion on whether this is a configuration
Emacs supports?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 9256-done <at> debbugs.gnu.org (full text, mbox):

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 1 (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 #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9256: Erroneous output from "verify-visited-file-modtime"
 (fileio.c)
Date: Mon, 20 Jan 2020 15:36:53 +0000

On Mon 20 Jan 2020, Paul Eggert wrote:

>> 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.

This patch breaks the build for Windows, as it appears that MinGW does
not have openat:

  CCLD     temacs.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sysdep.o: in function `emacs_openat':
C:/emacs/git/emacs/master/src/sysdep.c:2486: undefined reference to `openat'
C:/emacs/git/emacs/master/src/sysdep.c:2486:(.text+0x1359): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `openat'
collect2.exe: error: ld returned 1 exit status

Presumably this will need updates to w32.c to add the necessary support.

    AndyM

Message #23 received at 9256 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 9256 <at> debbugs.gnu.org
Subject: Re: bug#9256: Erroneous output from "verify-visited-file-modtime"
 (fileio.c)
Date: Mon, 20 Jan 2020 19:20:52 +0200

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Mon, 20 Jan 2020 15:36:53 +0000
> 
> > As I think both issues in the bug report have been addressed, I'm boldly closing it.
> 
> This patch breaks the build for Windows, as it appears that MinGW does
> not have openat:

It does now.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9256: Erroneous output from "verify-visited-file-modtime"
 (fileio.c)
Date: Mon, 20 Jan 2020 18:06:39 +0000

On Mon 20 Jan 2020, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Mon, 20 Jan 2020 15:36:53 +0000
>> 
>> > As I think both issues in the bug report have been addressed, I'm boldly closing it.
>> 
>> This patch breaks the build for Windows, as it appears that MinGW does
>> not have openat:
>
> It does now.

Thanks Eli, confirmed fixed.

    AndyM

Previous Next

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