On Fri, Sep 25, 2026 at 02:12:34PM +0100, Pádraig Brady wrote: > We have seen ctime not being updated when only one of atime or mtime was > being updated, > and have workarounds in gnulib for that. But not when we're updating both, > like a > default touch(1) should do. Does the system touch(1) cause the same issue?
Yes. > The output from `grep -Fi utime lib/config.h` would be useful also > to determine what gnulib is detecting on your system. # grep -Fi utime work/coreutils-9.12/lib/config.h /* Define to 1 if futimesat mishandles a NULL file name. */ /* #undef FUTIMESAT_NULL_BUG */ whether the gnulib module fdutimensat shall be considered present. */ #define GNULIB_FDUTIMENSAT 1 /* Define to 1 when the gnulib module futimens should be tested. */ #define GNULIB_TEST_FUTIMENS 1 /* Define to 1 when the gnulib module utime should be tested. */ #define GNULIB_TEST_UTIME 1 /* Define to 1 when the gnulib module utimensat should be tested. */ #define GNULIB_TEST_UTIMENSAT 1 /* Define to 1 if you have the `futimens' function. */ #define HAVE_FUTIMENS 1 /* Define to 1 if you have the `futimes' function. */ #define HAVE_FUTIMES 1 /* Define to 1 if you have the `futimesat' function. */ /* #undef HAVE_FUTIMESAT */ /* Define to 1 if you have the 'lutimens' function. */ #define HAVE_LUTIMENS 1 /* Define to 1 if you have the `lutimes' function. */ #define HAVE_LUTIMES 1 /* Define to 1 if utimensat works, except for the trailing slash handling. */ /* #undef HAVE_NEARLY_WORKING_UTIMENSAT */ /* Define to 1 if you have the 'utime' function. */ #define HAVE_UTIME 1 /* Define to 1 if you have the 'utimens' function. */ #define HAVE_UTIMENS 1 /* Define to 1 if you have the `utimensat' function. */ #define HAVE_UTIMENSAT 1 /* Define to 1 if you have the <utime.h> header file. */ #define HAVE_UTIME_H 1 /* Define if utimes works properly. */ #define HAVE_WORKING_UTIMES 1 /* Define to 1 if utime needs help when passed a file name with a trailing /* #undef REPLACE_FUNC_UTIME_FILE */ > What file system type is this? My first test was on tmpfs. I reproduced it with NetBSD's tools: #!/bin/sh touch a || fail=1 btime=$(stat -f %B a) || fail=1 atime=$(stat -f %a a) || fail=1 ctime=$(stat -f %c a) || fail=1 mtime=$(stat -f %m a) || fail=1 echo $btime $atime $ctime $mtime Running this twice on tmpfs gives: # ~/nbtest.sh 1790414618 1790414618 1790414618 1790414618 # ~/nbtest.sh 1790414618 1790414620 1790414618 1790414620 > Does it happen on other file system types? It's different on ffs: # ./nbtest.sh 1790414514 1790414604 1790414604 1790414604 # ./nbtest.sh 1790414514 1790414611 1790414611 1790414611 So... is this a bug in tmpfs or usual variation? Thomas
