Three bytes in a zip file
Michael Schierl
schierlm at gmx.de
Fri Apr 7 11:31:24 UTC 2023
Hello John,
Am 07.04.2023 um 03:56 schrieb John Gilmore:
> Larry Doolittle <larry at 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
More information about the rb-general
mailing list