fix(hardlink): content freshness moved switches, it was not withdrawn #15

Merged

claude merged 2 commits from chore/checksum-freshness into main 2026-08-27 03:20:03 +00:00

Conversation 2 Commits 2 Files Changed 5

+164 -66

2 Commits

Author	SHA1	Message	Date
claude	fa3cef53e0	docs(ci): the nightly does enable content freshness, as of 2026-08-26 ... The README's CI section still described the nightly toolchain step as buying nothing: "which no nightly currently enables, so it is skipped and the step is kept only against the day upstream restores it". That sentence predates this branch and states as fact the exact reading the rest of the PR retracts. Three things in this PR falsify it. The corrected `env:` block at README.md:110-117 records that since cargo PR #17382 (2026-08-22) the `-Z` gate only unlocks the feature and `build.fingerprint` selects it, so setting both turns it on. The corrected workflow comment in .gitea/workflows/ci.yaml says "as of 2026-08-26 it does". And this branch's own CI run printed `=== checksum-freshness mode: on ===` and `hardlink-clone-selftest: 4 assertions passed` on 1.100.0-nightly (787af2b8c 2026-08-25) — the scenario is not skipped, it runs. The paragraph also carried no date, which is the failure mode every other block this PR touched was rewritten to prevent. The replacement is dated and names the toolchain, matching the corrected blocks elsewhere. It deliberately stops short of "the scenario always runs": the suite still settles the question by experiment on every run and still skips loudly when it cannot measure, so the step is not unconditionally exercised. Saying otherwise would trade one overclaim for its mirror. Docs-only; no behaviour change.	2026-08-26 20:02:02 -05:00
claude	554310186f	fix(hardlink): content freshness moved switches, it was not withdrawn ... `unshare_mutable_paths`' comment recorded that upstream had stopped rewriting `dep-<target>` in place, on a measurement taken against 1.100.0-nightly. It had not. Two unrelated cargo changes landed within four days of each other and between them moved the switch that turns the behaviour on and the path it writes to: - cargo PR #17382 (2026-08-22) demoted `-Z checksum-freshness` to a gate and gave `build.fingerprint` the choice, defaulting to `mtime`. Setting only the gate is accepted and does nothing, which is exactly the result that was read as a withdrawal. - build-dir layout v2 (cargo PR #17354, stable 1.100.0 on 2026-11-12, nightly default since 1.99) moved the file from `.fingerprint/<unit>/dep-*` to `build/<pkg>/<hash>/fingerprint/dep-*`. Measured 2026-08-26 on 1.100.0-nightly (e8cb624d5): same toolchain, same clone procedure, one env var apart — with the gate alone a `cp -al` clone mutates only the build/ and *.d families; add `CARGO_BUILD_FINGERPRINT=content` and the source's dep-info file is mutated through the shared inode again. The hazard is intact. So the suite now exports both switches, and its strongest scenario runs again on current nightlies — verified passing against both layouts. Its control note learned the v2 path too: it looked for the v1 path only, and so printed "does NOT rewrite ... in place" three lines beneath a listing that showed the rewrite. Every claim these comments make is now dated and cited, because the defect being fixed is a comment that cited one measurement and silently stopped reproducing. Layout v2 also drags the artifacts under `build/`, which collapses this function's real-copy set from 21.3% of a target dir to 99.998%. That is a live cost, not a correctness problem, and it is filed as gitdan-actions#14 rather than fixed here. Part of daniel/gitdan#62.	2026-08-26 19:48:07 -05:00