This mitigates and probably can even be considered to fix #1491, at least with respect to the main variant of that issue where the problem is solely due to the format of the -d operand and not to the range of supported values.
For each edge-of-range touch, if at first it fails, this will try it rounded to the nearest more extreme value in seconds, which some implementations will accept and clip it at or near the most extreme value in the range that it was going for.
This should not lead to any unexpected or harder-to-diagnose errors because the one test that uses this fixture deliberately avoids asserting anything about the actual timestamps, anticipating that they may be close-by values instead:
However, if it is intended that touch fail and bring down the test when it cannot specify nanoseconds, then that might be a reason not go with this change.
Note that while, before this change, the test fails (due to the fixture failing) when touch rejects nanoseconds, it would still pass if the nanoseconds are ignored. As noted in #1491, I think that happens more often than may have been anticipated, and I wonder if really it might be better to use single touch commands (no &&) with more portable date strings.
This fixture's previous code did not seem to account for or explain the intended behavior with respect to time zone, and I have not attempted to address that here either.
I have verified locally that all tests pass on the Alpine Linux 3.17 system on which I discovered #1491. This includes from_path_no_follow, which failed on that system prior to the changes here.
This mitigates and probably can even be considered to fix #1491, at least with respect to the main variant of that issue where the problem is solely due to the format of the
-doperand and not to the range of supported values.For each edge-of-range
touch, if at first it fails, this will try it rounded to the nearest more extreme value in seconds, which some implementations will accept and clip it at or near the most extreme value in the range that it was going for.This should not lead to any unexpected or harder-to-diagnose errors because the one test that uses this fixture deliberately avoids asserting anything about the actual timestamps, anticipating that they may be close-by values instead:
https://github.com/Byron/gitoxide/blob/29898e3010bd3332418c683f2ac96aff5c8e72fa/gix-index/tests/index/fs.rs#L8-L9
However, if it is intended that
touchfail and bring down the test when it cannot specify nanoseconds, then that might be a reason not go with this change.Note that while, before this change, the test fails (due to the fixture failing) when
touchrejects nanoseconds, it would still pass if the nanoseconds are ignored. As noted in #1491, I think that happens more often than may have been anticipated, and I wonder if really it might be better to use singletouchcommands (no&&) with more portable date strings.This fixture's previous code did not seem to account for or explain the intended behavior with respect to time zone, and I have not attempted to address that here either.
I have verified locally that all tests pass on the Alpine Linux 3.17 system on which I discovered #1491. This includes
from_path_no_follow, which failed on that system prior to the changes here.