Hello John,
Am 07.04.2023 um 03:56 schrieb John Gilmore:
Larry Doolittle <la...@doolittle.boa.org> wrote:
$ diff <(ls --full-time -u fab-ea2bb52c-ld) <(ls --full-time -u fab-ea2bb52c-mb)
22c22
< -rw-r--r-- 1 redacted redacted 644661 2023-04-04 18:10:00.000000000 -0700
marble-ipc-d-356.txt
---
-rw-r--r-- 1 redacted redacted 644661 2023-04-06 00:25:03.000000000 -0700
marble-ipc-d-356.txt
So I'm guessing that even before the zip file is re-created, the rebuild
process is leaking the rebuild timestamp into the last-modified metadata
of the generated marble-ipc-d-356.txt file?
atime is not the same as mtime. -u switch shows atime.
That seems like it should
be handled by the build process explicitly setting its timestamp to
something related to the last-source-code-checkin time (with "touch
--date=XXX") rather than to current time.
Larry's script already called touch immediately before zip. But I assume
the nature of atime can mean that any other process may have "won the
race" and accessed the file just in between these two lines.
Truncating the timestamps to DOS timestamps wouldn't work to eliminate
this difference anyway, since the date in the two files is two days
different; DOS timestamps are accurate to 2 seconds, as I recall.
The DOS timestamps encode only mtime, and not ctime or atime.
Regards,
Michael
