GNU bug report logs - #8371
auto-revert-mode check

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ken Raeburn <raeburn <at> raeburn.org>
Subject: bug#8371: closed (Re: bug#8371: auto-revert-mode check)
Date: Thu, 13 Jun 2013 16:28:03 +0000

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

Your bug report

#8371: auto-revert-mode check

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 8371 <at> debbugs.gnu.org.

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

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

From: Glenn Morris <rgm <at> gnu.org>
To: 8371-done <at> debbugs.gnu.org
Subject: Re: bug#8371: auto-revert-mode check
Date: Thu, 13 Jun 2013 12:27:49 -0400

Version: 24.3

File time stamps are higher resolution now, so between that and
improvements to reverting, whatever issue there was here is probably
fixed.

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

From: Ken Raeburn <raeburn <at> raeburn.org>
To: bug-gnu-emacs <at> gnu.org
Subject: auto-revert-mode check
Date: Mon, 28 Mar 2011 18:22:04 -0400

It looks like auto-revert-mode in 23.2 checks the file timestamp to see when the file is updated.  But I often see the file as having an extra line or two that Emacs doesn't pick up for a long time, until something else is added to the file.  I don't have time to look into it right now at work, but my guess is either/both (1) Emacs records the "changed" timestamp after reading the updated content, so the timestamp could correspond to an updated version relative to the buffer content; (2) Emacs isn't recording/checking the timestamp with enough granularity (which on this NFS file server and Linux NFS client, appears to be a millisecond, though file-attributes appears to return no sub-second component), so updates within the space of a second after Emacs rereads the file aren't detected.

Checking file size too would help, at least for files updated by appending.

I think file-attributes needs to be able to return sub-second granularity timestamps for modern operating systems, though it may require using non-standard interfaces, like GNU libc's stat.st_atim.tv_nsec or stat.st_atimensec field.

I'll see if I have time to look into this later this week.

Ken

Previous Next

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