[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution

[Nick Bowler]

On 14/01/2023, Zack Weinberg <zack@owlfolio.org> wrote:
> On Sat, Jan 14, 2023, at 7:18 PM, Mike Frysinger wrote:
>> Rather than assume such coarse delays, re-use existing logic for
>> probing the current filesystem resolution.  This speeds up the
>> testsuite significantly.>
[...]
> No objection to this patch in itself, but I want to make sure you're
> aware that the "existing logic for probing the current filesystem
> resolution" has a bug where, if you start running the script at just
> the wrong time, it will erroneously detect a finer timestamp resolution
> than the system actually supports.   For instance, if we can sleep for
> 0.1 second, the filesystem's timestamp resolution is 2s, and the sleep
> loop happens to start executing at 0h00m59.9s, then it'll tick over to
> 0h01m00.0s and conftest.file.a and conftest.file.b will have distinct
> timestamps.  This happens to me quite reliably: whenever I try to
> run the Automake test suite inside AFS, I'll get a couple of spurious
> test failures because of this bug.

I don't know how exactly this delay is used in the test suite, but if
the goal is just to "reliably wait until newly-created files have
different timestamps from prior-created files, without waiting
substantially longer than required", I've had good results with a
pattern like this in my own test suites (instead of sleeping for a
predetermined amount of time):

  cat >uptodate.mk <<'EOF'
  old: new
        false
EOF
  touch old; touch new
  while make -f uptodate.mk >/dev/null 2>&1; do
    touch new
  done

Cheers,
  Nick