[Top][All Lists]

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

bug#9000: patch for higher-resolution time stamps

From: Paul Eggert
Subject: bug#9000: 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: 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:


Stefan asked me in
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
to have a bug report for this issue.

reply via email to

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