Run #4284's diagnostic (iter36) confirmed xorriso ignores every
date-setting command we throw at it for the node it just -updated:
flag=0x0e → CREATION + MODIFICATION + ACCESS (short form)
CREATION ✅ (set from source file btime via touch -d):
7e 05 08 00 2c 3a 00 (= SOURCE_DATE_EPOCH)
MODIFICATION ❌ (still wall-clock):
A=7e 05 08 01 02 2c 00 B=7e 05 08 01 12 33 00
ACCESS ❌ (still wall-clock):
A=7e 05 08 01 02 2c 00 B=7e 05 08 01 12 32 00
Tested across iters 34-36:
* `-alter_date_r all "=N" /` — only fixed CREATION (b)
* `-alter_date all "=N" path` after -update — same
* `-volume_date c m x f u s "=N"` — volume-level only
* `touch -d "@N" "${new_sqfs}"` before — fixed CREATION via btime
* various orderings, with/without `--` terminators
None override xorriso's wall-clock stamping of MOD/ACCESS at -commit.
Concede that fight and just patch the bytes after xorriso writes the
ISO. We KNOW exactly what's wrong — the TF entry for
/live/filesystem.squashfs has its CREATION slot correct (= 7-byte
ISO9660 short-form encoding of SOURCE_DATE_EPOCH) but MODIFICATION
and ACCESS still hold the post-process commit time. So copy the 7
CREATION bytes over the 7 MODIFICATION bytes and 7 ACCESS bytes.
The patcher (embedded Python, since silvermetal-builder ships
python3):
* Finds every TF entry header (`54 46 1a 01 0e`) near the
"filesystem.squashfs" NM tag (96-byte window — anchors both
ends so we don't touch some other file's TF entry).
* Copies CREATION (offset +5..+12) onto MODIFICATION (+12..+19)
and ACCESS (+19..+26).
* Skips entries already correct (so re-running is a no-op).
* Reports how many entries were patched.
This is surgical: only the entry we know is broken, and only when
its MOD/ACCESS actually differ from the (known-correct) CREATION.
If the next run still drifts, the diagnostic byte-offset will tell
us where the residual leak is (almost certainly in some volume
descriptor field we haven't covered yet — at which point we extend
the patcher).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>