Re: sub-second time stamp issues

[Ralf Wildenhues]

[ moving from automake-patches, this is
<http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3638/focus=3770> ]

* 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?

Thanks,
Ralf

    `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
    <http://lists.gnu.org/archive/html/automake-patches/2009-12/msg00017.html>.

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:
 
 @example
 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