[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Nick Bowler
Subject: [bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution
Date: Sat, 14 Jan 2023 22:54:47 -0500

On 14/01/2023, Zack Weinberg <> 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 > <<'EOF'
  old: new
  touch old; touch new
  while make -f >/dev/null 2>&1; do
    touch new


reply via email to

[Prev in Thread] Current Thread [Next in Thread]