Jeff King <peff@xxxxxxxx> writes: > On Wed, Apr 01, 2020 at 08:06:47PM -0400, Derrick Stolee wrote: > > I wonder if that would run afoul of the same "mtime and system clock are > not quite the same" issue we saw recently in [1]. I had the exact thing in mind, which was why I suggested "chmtime" in the first place (the second reason was that it was easy to do relative time using the tool than "date + touch"), but I missed that the tool has a mode that uses timestamp relative to system clock. > I think it might not because we're only comparing mtimes set > through the same mechanism (find the system time, subtract from > it, and assign to mtime). If system time is monotonically > increasing at any rate, that would produce the desired effect. But in this particular case, I think, even though setting the filesystem timestamp based on something that was obtained from the system clock feels as if we are asking for trouble, the values we later read back from the filesystem for executing the codepath being tested (namely, expiration logic) get compared with another value that is derived from from the system clock (i.e. expiration cutoff), so in that sense you might be able to argue that it is even more correct ;-)
