On 2026-08-16 10:36, Paul Eggert wrote:
On 2026-08-15 23:39, Andreas Schwab wrote:
It's still failing "the duplication of the file characteristics [...]
for any reason".
That depends on what one means by "failing". To help clarify this, I filed a bug
report with the POSIX folks <https://austingroupbugs.net/view.php?id=1997>; please feel
free to follow up there.
That bug report was resolved today, letting implementations downres the
destination timestamp in the usual way.
I looked to update the coreutils documentation accordingly, and found that it already
talked about the issue in its "File timestamps" chapter. However, the
discussion was too loose: it allowed mv to increase the destination timestamp, whereas it
should truncate toward minus infinity. Also, some of the chapter was simply wrong in the
light of POSIX.1-2024's wording in this area. I installed the attached documentation
patch to try to clear up matters.
From 3474738f1840b0547ce95ed9b7bcfeffc9b4a8d8 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email protected]>
Date: Mon, 14 Sep 2026 10:39:45 -0700
Subject: [PATCH] doc: File timestamps and POSIX.1-2024
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* doc/coreutils.texi (File timestamps):
Update in the light of <https://bugs.gnu.org/13601#46>,
<https://austingroupbugs.net/view.php?id=1997>, and
POSIX.1-2024 Base Specifications 4.12 “File Times Update”.
---
doc/coreutils.texi | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 46854db4a..b769e64c1 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -19264,21 +19264,26 @@ doesn't change, nor does it modify the file, so the mtime doesn't
change. Yet, something about the file itself has changed, and this
must be noted somewhere. This is the job of the ctime field. This is
necessary, so that, for example, a backup program can make a fresh
-copy of the file, including the new permissions value. Another
-operation that modifies a file's ctime without affecting the others is
-renaming.
+copy of the file, including the new permissions value.
+For ctime purposes a file's status includes its mtime but not its atime,
+which means reading updates atime but writing updates both mtime and ctime.
+It is unspecified whether merely renaming a file updates its ctime,
+though renaming does update the mtime and ctime of the parent
+directory or directories involved.
Naively, a file's atime, mtime, and ctime are set to the current time
whenever you read, write, or change the attributes of the file
-respectively, and searching a directory counts as reading it. A
-file's atime and mtime can also be set directly, via the
+respectively. A file's timestamps can also be set directly, via the
@command{touch} command (@pxref{touch invocation}). In practice,
though, timestamps are not updated quite that way.
For efficiency reasons, many systems are lazy about updating atimes:
when a program accesses a file, they may delay updating the file's
atime, or may not update the file's atime if the file has been
-accessed recently, or may not update the atime at all. Similar
+accessed recently, or may not update the atime at all if the file system
+is read-only or is configured to ignore atime updates.
+When a directory is searched as part of file name resolution,
+no modern system updates the directory's atime. Similar
laziness, though typically not quite so extreme, applies to mtimes and
ctimes.
@@ -19287,8 +19292,11 @@ and these emulations may disagree with the naive interpretation. For
example, a system may fake an atime or ctime by using the mtime.
@cindex clock skew
-The determination of what time is ``current'' depends on the
-platform. Platforms with network file systems often use different
+The determination of what time is ``current'' depends on the situation.
+If the file is open by any process, the ``current'' time might be any
+time before the file ceases to be open, so long as the time precedes
+any inspection of or further change to the file's timestamp.
+Also, platforms with network file systems often use different
clocks for the operating system and for file systems; because
updates typically uses file systems' clocks by default, clock
skew can cause the resulting file timestamps to appear to be in a
@@ -19298,7 +19306,8 @@ program's ``future'' or ``past''.
When the system updates a file timestamp to a desired time @var{t}
(which is either the current time, or a time specified via the
@command{touch} command), there are several reasons the file's
-timestamp may be set to a value that differs from @var{t}. First,
+timestamp may be set to a value that loses low-order information
+and is therefore slightly less than @var{t}. First,
@var{t} may have a higher resolution than supported. Second, a file
system may use different resolutions for different types of times.
Third, file timestamps may use a different resolution than operating
--
2.53.0
