atime-on-use instead of mtime-on-use

[dcolascione]

Problem

mtime is explicitly a modification time, updating it when nothing's actually changed can confuse backup tools, dependency analysis systems, file indexers, and so on.

Proposed Solution

atime is explicitly an access-time field. It doesn't signal modification so doesn't have the same side effects that updating mtime has. While many Linux systems disable or throttle atime updtes, atime can be updated explicitly updated using utimes() in the same circumstances mtime is updated.

Notes

I'd expect updating atime instead of mtime in this feature to be a trivial enhancement.

[Eh2406]

Are you sure that systems that disable the use of atime will let you set it manually? I believe there are systems where that field is thrown away. You can write to it, but even if you do the next time you read you will just get mtime. It's always possible that I remember incorrectly.

The other difficult problem is interoperability between versions That depend on mtime and versions that depend on atime. Whether we have to worry about that depends on exactly which files are causing troubles. So which files exactly do you want to back up or index where we adjust mtime without making meaningful changes?

[weihanglo]

Are you sure that systems that disable the use of atime will let you set it manually? I believe there are systems where that field is thrown away.

Disabling atime is pretty common AFAIK. Regardless we have some other options in parallel, -Zmtime-on-use and checksum-freshness. The latter is more the direction we are working toward.

But yeah, I think Eh2406's is right that we need to know the context more before moving on.

@rustbot label +S-needs-info -S-triage

[dcolascione]

Explicit atime update works fine even on systems with noatime.

Z$ zsh test-atime.sh
+test-atime.sh:13> rm -f foo
+test-atime.sh:14> echo hello
+test-atime.sh:15> stat -c 'atime: [%x] mtime: [%y]' foo
atime: [2026-07-17 16:29:09.577327507 -0400] mtime: [2026-07-17 16:29:09.577327507 -0400]
+test-atime.sh:16> echo hello
+test-atime.sh:17> stat -c 'atime: [%x] mtime: [%y]' foo
atime: [2026-07-17 16:29:09.577327507 -0400] mtime: [2026-07-17 16:29:09.578327639 -0400]
+test-atime.sh:18> touch -a foo
+test-atime.sh:19> stat -c 'atime: [%x] mtime: [%y]' foo
atime: [2026-07-17 16:29:09.580327904 -0400] mtime: [2026-07-17 16:29:09.578327639 -0400]
+test-atime.sh:20> findmnt -T . -n -o OPTIONS
rw,noatime,ssd,space_cache=v2,subvolid=2039,subvol=/rootfs

#!/usr/bin/env zsh
set -xeuo pipefail
rm -f foo
echo hello > foo
stat -c 'atime: [%x] mtime: [%y]' foo
echo hello > foo
stat -c 'atime: [%x] mtime: [%y]' foo
touch -a foo
stat -c 'atime: [%x] mtime: [%y]' foo
findmnt -T . -n -o OPTIONS

The other difficult problem is interoperability between versions That depend on mtime and versions that depend on atime.

You already have incompatibilities between versions that don't update times at all and ones that do, so what's the trouble?

So which files exactly do you want to back up or index where we adjust mtime without making meaningful changes?

Anything that depends on evaluating mtimes to look for cache freshness (e.g. as part of a larger build system) will observe mtime updates as false dirtying.

[dcolascione]

And for my purposes, I'm using atime to do my own LRU-based cache and build-output pruning. The set of unwante side effects involved in updating atimes an output's transitive closure of inputs is much smaller than that of mtimes. I'll just arrange for atimes to get updated, then prune to desired output size lowest-atime-first. Nice and simple.