Re: _AM_FILESYSTEM_TIMESTAMP_RESOLUTION incorrect result (was Re: make check(s) pre-release problems)

Hi Zack,

    Date: Fri, 07 Oct 2022 11:35:41 -0400
    From: Zack Weinberg <[email protected]>

    [...]
    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