emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#9000: closed (patch for higher-resolution time sta


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#9000: closed (patch for higher-resolution time stamps)
Date: Fri, 22 Jun 2012 21:26:02 +0000

Your message dated Fri, 22 Jun 2012 14:21:50 -0700
with message-id <address@hidden>
and subject line patch for higher-resolution time stamps
has caused the debbugs.gnu.org bug report #9000,
regarding patch for higher-resolution time stamps
to be marked as done.

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


-- 
9000: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9000
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: patch for higher-resolution time stamps Date: Mon, 04 Jul 2011 23:40:43 -0700 User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
Currently, Emacs supports time stamps to at most microsecond
resolution, and often to only 1-second resolution, even though most
modern systems have nanosecond-resolution time stamps for clock and
file time stamps.  This leads to some problems, for example:

 * "C-u M-x copy-file RET A RET B" discards the fractional part of A's
   time stamp when copying A to B (except for Windows, which I've been
   told uses special code to preserve the time stamp correctly).

 * The file-attributes function truncates file time stamps to
   one-second resolution, making it impossible for a dired written in
   Emacs to emulate the behavior of "ls --full-time".

 * (format-time-string "%s.%N") is supposed to output
   nanosecond-resolution time stamps, but on the Emacs trunk it always
   outputs a multiple of one microsecond, even when the system clock
   supports nanosecond resolution.

 * If some other process modifies a file during the same second that
   Emacs gets the file's time stamp, Emacs won't notice the conflict,
   as the visited-file-modtime function supports only 1-second
   resolution.  If Emacs used nanosecond-resolution time stamps, this
   race condition would be much less likely.

None of these problems are fatal, but they are annoyances that could
lead to real problems (e.g., when working with "make", which uses
high-resolution file time stamps).

I've proposed a patch for this:

http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00015.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00016.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00017.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00018.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00019.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00020.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00021.html

Stefan asked me in
<http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00069.html>
to make the patch more upward-compatible, by appending a new
picosecond count to the end of the time stamp list, rather than
changing the microsecond to a nanosecond count (which would likely
break more code).  I'll do that soon, but thought I'd first file a bug
report to make this whole issue easier to track.

In part I am also following up to Stefan's suggestion
<http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00217.html>
to have a bug report for this issue.



--- End Message ---
--- Begin Message --- Subject: patch for higher-resolution time stamps Date: Fri, 22 Jun 2012 14:21:50 -0700 User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
No further comment and the patch seems ripe
so I installed it into the trunk as bzr 108687
and am marking this bug as done.  I'll CC: this
to Eli as it affects the Microsoft ports.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]