From 7fe75b236cd05c1d05953511e4c19a74265de92f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 28 Dec 2024 16:04:09 -0800 Subject: [PATCH] Update timestamp doc * doc/autoconf.texi (Limitations of Usual Tools) (Timestamps and Make): Modernize discussion a bit, and give a downside of the GNU make approach. --- doc/autoconf.texi | 38 ++++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/doc/autoconf.texi b/doc/autoconf.texi index dd0b1fa2b..29e4a78c2 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -19067,17 +19067,17 @@ have timestamps with 1-nanosecond resolution. Unfortunately, some older which can cause the destination file to appear 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. Less-ancient @command{cp} -implementations such as GNU Core Utilities 5.0.91 (2003) use -@code{utimes}, which has 1-microsecond resolution. Modern -implementations such as GNU Core Utilities 6.12 (2008) can set timestamps to -the full nanosecond resolution, using the modern system calls +@code{utime}, which has 1-second resolution. Since +GNU Core Utilities 6.12 (2008), GNU @command{cp} can set timestamps to +the full nanosecond resolution, using the system calls @code{futimens} and @code{utimensat} when they are available. As of -2011, though, many platforms do not yet fully support these new system -calls. +2024, though, some platforms (such as AIX 7.3) still have @samp{cp -p} +that supports only 1-second resolution, and some operating systems +and file systems have similar limitations even when running +GNU @command{cp}. -Bob Proulx notes that @samp{cp -p} always @emph{tries} to copy -ownerships. But whether it actually does copy ownerships or not is a +Although @samp{cp -p} always @emph{tries} to copy +ownerships, whether it actually does so is a system dependent policy decision implemented by the kernel. If the kernel allows it then it happens. If the kernel does not allow it then it does not happen. It is not something @command{cp} itself has control @@ -21238,7 +21238,7 @@ fractional part, which can lead to incorrect results. Normally this is not a problem, but in some extreme cases you may need to use tricks like @samp{sleep 1} to work around timestamp truncation bugs. -Commands like @samp{cp -p} and @samp{touch -r} typically do not copy +Traditionally, commands like @samp{cp -p} and @samp{touch -r} did not copy file timestamps to their full resolutions (@pxref{touch, , Limitations of Usual Tools}). Hence you should be wary of rules like this: @@ -21259,14 +21259,20 @@ dest-stamp: src @end example Apart from timestamp resolution, there are also differences in handling -equal timestamps. HP-UX @command{make} updates targets if it has the -same timestamp as one of its prerequisites, in violation of POSIX rules. +equal timestamps. Although POSIX suggests that @command{make} update a +target with the same timestamp as its newest prerequisite, only +HP-UX @command{make} is known to do so; GNU and other @command{make} +implementations do not update, a behavior that POSIX also allows. -This can cause spurious rebuilds for repeated runs of @command{make}. -This in turn can cause @command{make} to fail if it tries to rebuild +The HP-UX behavior can cause spurious rebuilds +and this in turn can cause @command{make} to fail if it tries to rebuild generated files in a possibly read-only source tree with tools not -present on the end-user machine. Use GNU @command{make} instead. - +present on the build machine. Conversely, if a source file is updated +immediately after running @command{make} in a file system with +low-resolution timestamps, the GNU behavior can cause a later +@command{make} to neglect rebuilds and quietly generate incorrect results. +To avoid both these problems, use GNU @command{make} on a platform +with high-resolution timestamps. @c ======================================== Portable C and C++ Programming -- 2.47.3