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.

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index dd0b1fa2b4fe424c3ae3959cd2c9fe987ce2c2c5..29e4a78c21a8984150d30246720876b91bef4b56 100644 (file)
--- 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