[Top][All Lists]

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

Re: sub-second time stamp issues

From: Ralf Wildenhues
Subject: Re: sub-second time stamp issues
Date: Sun, 10 Jan 2010 19:44:39 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

[ moving from automake-patches, this is
<> ]

* Ralf Wildenhues wrote on Wed, Dec 09, 2009 at 08:08:58PM CET:
> * Peter Breitenlohner wrote on Mon, Dec 07, 2009 at 03:08:34PM CET:
> > On Fri, 4 Dec 2009, Ralf Wildenhues wrote:
> > 
> >  ~> touch -r file2 file3; cp -p file2 file4; ls -l --full-time file?
> >  >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.460965546 +0100 file1
> >  >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.964956156 +0100 file2
> >  >  -rw-r--r-- 1 peb THEORY 0 2009-12-07 14:20:05.000000000 +0100 file3
> >  >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:05.000000000 +0100 file4
> > As I knew already from trying to understand a similar problem, 'cp -p' and
> > 'touch -r' both round sub-seconds, whereas tar and rsync truncate them.
> Ouch.  That's even worse.  The text at 'Timestamps and Make' in the
> Autoconf manual needs updating for this.
> That can hurt user-written makefile rules that use `cp -p' or `touch
> -r'.  sanity.m4 can't help it really, because this can at best cause
> spurious rebuilds of all kinds of things, and at worst not cause
> updating of some targets.

Proposed patch for the Autoconf manual.  OK?


    `touch -r' and `cp -p' might round, rather than truncate, timestamps.
    * doc/autoconf.texi (Limitations of Usual Tools)
    (Timestamps and Make): Document rounding of time stamps.
    Report by Peter Breitenlohner against Automake in

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index ccdb6fc..3399018 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17460,8 +17460,8 @@ Limitations of Usual Tools
 Traditionally, file timestamps had 1-second resolution, and @samp{cp
 -p} copied the timestamps exactly.  However, many modern file systems
 have timestamps with 1-nanosecond resolution.  Unfortunately, @samp{cp
--p} implementations truncate timestamps when copying files, so this
-can result in the destination file appearing to be older than the
+-p} implementations either truncate or round timestamps when copying files,
+so this can result in the destination file appearing to be older than the
 source.  The exact amount of truncation depends on the resolution of
 the system calls that @command{cp} uses; traditionally this was
 @code{utime}, which has 1-second resolution, but some newer
@@ -19436,8 +19436,9 @@ Timestamps and Make
 like @samp{sleep 1} to work around timestamp truncation bugs.
 Commands like @samp{cp -p} and @samp{touch -r} typically do not copy
-file timestamps to their full resolutions (@pxref{touch, , Limitations of Usual
-Tools}).  Hence you should be wary of rules like this:
+file timestamps to their full resolutions (@pxref{touch, , Limitations
+of Usual Tools}), but they might round the subsecond part.  Hence you
+should be wary of rules like this:
 dest: src
@@ -19455,7 +19456,11 @@ Timestamps and Make
         date >dest-stamp
 @end example
+To avoid issues with rounded timestamps, you might need to introduce
address@hidden 1} in rules depending on targets that are created with
address@hidden -p} and @samp{touch -r}, to avoid @command{make} seeing them
+as older than their prerequisites.  Since this is error-prone, such
+rules are best avoided.
 @c ======================================== Portable C and C++ Programming

reply via email to

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