Hi Zack,
Date: Fri, 07 Oct 2022 11:35:41 -0400
From: Zack Weinberg <z...@owlfolio.org>
[...]
the filesystem timestamp resolution was incorrectly detected:
Your analysis sounds plausible to me, but it's not obvious to me how
best to fix it. ls --full-time or stat may not be available.
Maybe just do the test again if the first ls -t "succeeds", i.e., if the
first 0.1sec straddles a second boundary, the second presumably won't?
Or is there a better way?
I wonder if you could easily make a patch for it (in m4/sanity.m4), if
you already have a setup on a second-granularity fs? (I don't.)
--thanks, karl.
[...]
The filesystem I'm working in only records timestamps at second
granularity. (I don't know why ls is printing .000000001 instead of
.000000000 but it's always .000000001.)
$ touch A && sleep 0.1 && touch B && ls --full-time -t A B
-rw-r--r-- 1 zweinber users 0 2022-10-07 11:20:05.000000001 -0400 A
-rw-r--r-- 1 zweinber users 0 2022-10-07 11:20:05.000000001 -0400 B
I *think* this is a bug in _AM_FILESYSTEM_TIMESTAMP_RESOLUTION where, if
it starts looping at *just the wrong time*, the first 0.1-second sleep
will straddle a second boundary and we'll break out of the loop
immediately and think we have 0.1-second timestamp resolution.
zw
