--- Begin Message ---
|
Subject: |
sanity.m4: a millisecond is too fast? |
|
Date: |
Mon, 8 Jan 2024 08:44:31 -0700 |
The plethora of bug reports from the last pretest make me believe that
many systems simply cannot (currently) reliably handle a millisecond
difference in mtime. Despite the latest careful test that Zack
implemented _AM_FILESYSTEM_TIMESTAMP_RESOLUTION, pretesters continued to
report "random" errors.
My current idea is to only try for a hundredth of a second. This makes
the automake test suite take a few extra minutes to run (something like
12 vs. 10, in my trials), but hopefully will generate less false
positives, which would be well worth it, IMHO.
It seems impossible to truly test for a capable (file)system, or
otherwise figure out the underlying problem. At least, I don't have any
good ideas. The whole idea of the am test command $sleep seems like a
bogus workaround to me. On the other hand, failing a true fix, I think
it needs to be added in many more places, with the advent of subsecond
mtimes. Debugging all this is nowhere on my list :(.
Anyway, if anyone has any ideas about how to better proceed, please
speak up. Else I'll install this trivial patch, and we'll see how the
next pretest goes. --thanks, karl.
--- a/m4/sanity.m4
+++ b/m4/sanity.m4
@@ -34,7 +34,7 @@ am_cv_filesystem_timestamp_resolution=2
# Only try to go finer than 1s if sleep can do it.
am_try_resolutions=1
if $am_cv_sleep_fractional_seconds; then
- am_try_resolutions="0.001 0.01 0.1 $am_try_resolutions"
+ am_try_resolutions="0.01 0.1 $am_try_resolutions"
fi
# In order to catch current-generation FAT out, we must *modify* files
--- End Message ---