fix(hardlink): content freshness moved switches, it was not withdrawn #15
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: daniel/gitdan-actions#15
Reference in New Issue
Block a user
Summary
unshare_mutable_pathscomment inscripts/cache-lib.sh: content freshness was not withdrawn upstream and Cargo has not stopped rewritingdep-<target>in place. Two unrelated cargo changes moved the on-switch and the path, four days apart.hardlink-clone-selftest.shnow exports both switches content freshness needs, and its strongest scenario — the source's-next-build check — runs and passes again on current nightlies.does NOT rewrite ... in placethree lines beneath a listing that showed the rewrite.cache-lib.sh,hardlink-clone-selftest.sh,restore-mtimes.sh,README.mdand the CI workflow comment.Opened non-draft because it touches
.gitea/workflows/ci.yaml(a comment only), so the workflow under test runs.Why
daniel/gitdan#62recorded three measurements against 1.100.0-nightly and drew the reasonable conclusion that upstream had stopped writing the dep-info file in place. The ticket also asked the right question about it: is the aliasing hazard genuinely gone or merely relocated? A relocated one is worse than a removed one, because nothing here is looking for it.It was relocated — twice over, and neither move was about hardlinks.
Key findings
1. The on-switch moved; the hazard is intact. cargo PR #17382
feat(config): Add build.fingerprint, merged 2026-08-22, demoted-Z checksum-freshnessto a gate. It now only unlocks the feature;build.fingerprintselects it and defaults to"mtime". SoCARGO_UNSTABLE_CHECKSUM_FRESHNESS=truealone is accepted and does nothing — precisely the "flag accepted, mtime anyway" result the ticket measured.Measured 2026-08-26 on cargo 1.100.0-nightly (e8cb624d5 2026-08-22), same toolchain and same
cp -alclone procedure, one env var apart:CARGO_UNSTABLE_CHECKSUM_FRESHNESS=truebuild/.../out/gen.txt,run/root-output,out/*.d,libprobe.dCARGO_BUILD_FINGERPRINT=contentbuild/probe/<hash>/fingerprint/dep-lib-probeThe dep-info write is still there, still in place, still through the shared inode. It was switched off, not removed.
2. The path moved too. Build-dir layout v2 (
-Zbuild-dir-new-layout, cargo 1.91, PR #15848) became the nightly default in cargo 1.99 (PR #17258) and was stabilised by PR #17354, merged 2026-08-18, shipping in cargo 1.100.0 stable on 2026-11-12 (tracking #15010). Under v2 there is no<profile>/.fingerprintand no<profile>/deps; everything is regrouped per build unit under<profile>/build/<pkg>/<hash>/{fingerprint,out,run}/.Bracketed locally: cargo 1.97.1 and 1.98.0-nightly write v1, 1.100.0-nightly writes v2.
So
unshare_mutable_paths'-name .fingerprintclause matches nothing under a v2 Cargo, and the dep-info file is covered only because-name buildhappens to swallow its new home. Belt-and-braces by accident rather than by design — which is worth saying out loud in the comment, and now is.3. Answering the ticket's three questions directly.
dep-<target>in place, and is the hazard gone or relocated? — Upstream did not stop. Relocated, on both axes: the switch that enables it and the path it writes. Deliberate in the sense that both changes were intentional upstream work; neither was about in-place writing, which is unchanged.[unstable] checksum-freshness = truestill gates it;[build] fingerprint = "content"/CARGO_BUILD_FINGERPRINT=contentnow selects it. Not withdrawn, not stabilised, still nightly.dep-*clause become documentation? — No. It is still a live guard wherever content freshness is on. What it needs is a dated record of where the file now lives and of the fact that its own.fingerprintclause is dead under v2 — which is what this PR writes.4. What this PR deliberately does not fix. Layout v2 moved the artifacts under
build/alongside the metadata, sounshare_mutable_pathsreal-copies essentially the whole tree. Measured 2026-08-26, one scratch crate (serde + serde_json + regex), same sources both ways:Correctness is unaffected — the guarded file is still privately owned — but a hardlink clone that real-copies 99.998% of the tree is a
cp -awith extra steps. Changing the selection changes what gets hardlinked on every consumer, so it wants its own change and its own review: gitdan-actions#14, with the 2026-11-12 deadline recorded.Files affected
scripts/cache-lib.sh— theunshare_mutable_pathscomment. Both layout paths named; a dated "what upstream changed, and what it did not" section replacing the single-measurement claim; the v1 3.7% Bevy figure kept but labelled v1-only. No code change.scripts/hardlink-clone-selftest.sh— exportsCARGO_BUILD_FINGERPRINT=contentalongside the gate (and unsets both on a negative or unmeasured probe); control note's grep widened tofingerprint/.*dep-so it matches either layout; header rationale and the INACTIVE reason string corrected.README.md— the intro's corruption-path claim, the recommendedenv:block (now both variables), and the selftest table row.scripts/restore-mtimes.sh— the complementary-guarantee note names both variables..gitea/workflows/ci.yaml— the nightly step's comment said it "buys nothing today". It buys the strongest scenario in the suite again.Test plan
CI parity, run locally on
daniel-desktop:shellcheck -x --source-path=scripts scripts/*.sh— clean.bash scripts/selftest.sh— all 6 suites, all assertions pass.hardlink-clone-selftest.shspecifically, run against both layouts, because that is the change with behaviour in it:on.fingerprint/probe-<hash>/dep-lib-probe; clone shares 4 / owns 21onbuild/probe/<hash>/fingerprint/dep-lib-probe; clone shares 2 / owns 22Before this change, the same suite on 1.100.0-nightly reported
mode: offand 3 assertions — the fourth skipped.CARGO_BUILD_FINGERPRINT=contentis safe to export unconditionally: verified 2026-08-26 that cargo 1.93.1 stable and 1.96.0-nightly ignore the unknown key silently, with no warning and no behaviour change (both still measure ACTIVE from the gate alone).Nothing here ran against gitdan-ci or any shared cache volume; all experiments used throwaway crates under a scratch directory, plus a
nightly-2026-08-25toolchain installed with--profile minimal.Part of daniel/gitdan#62.
VERDICT: REQUEST-CHANGES
One finding, and it is the same class of defect this PR exists to repair — left standing in the same file the PR edits.
Headline finding — a retracted claim survives, undated, in
README.mdREADME.md:558-563(the CI section) still says the nightly toolchain step exists only in hope:That is precisely the "upstream withdrew content freshness" reading this PR retracts. It is falsified by the PR's own new text 480 lines above it (
README.md:114-117), by the corrected workflow comment (.gitea/workflows/ci.yaml:76-77, "as of 2026-08-26 it does"), and by this PR's own CI run: job 5417 prints=== checksum-freshness mode: on ===andhardlink-clone-selftest: 4 assertions passed. The paragraph carries no date, so a future reader has nothing to weigh it against — which is the exact failure mode the dated blocks elsewhere in this diff were written to prevent.docs-ship-with-codemakes a behaviour change that leaves a doc lying a request-changes finding rather than a nit, and the doc here is not incidental: it is the retracted claim, restated as fact, in the file the PR already opened. The fix is two sentences.Everything else below verified clean, and much of it verified independently rather than taken on the PR's word.
Wide pass — right change, right place
Yes. #62 is a
questionticket whose deliverable is a dated, citation-anchored correction, and that is what lands: every corrected block names its measurement date (2026-08-26) and its toolchain (1.100.0-nightly (e8cb624d5 2026-08-22)), and thecache-lib.shblock quotes the wrong reading it replaces before correcting it, so a reader can see what moved. The historical 3.7% Bevy figure is kept and relabelled v1-only rather than deleted. All three of #62's questions are answered explicitly, including the one it flagged as the worse outcome — the hazard was relocated, on both axes.The split against gitdan-actions#14 is honest. Nothing shipped here depends on the unfixed selection being right by design.
cache-lib.shsays outright that-name .fingerprintmatches nothing under v2 and that the dep-info file is covered only because-name buildhappens to swallow its new home — "belt-and-braces by accident, not by design". I confirmed that: under v2 the mutated file isdebug/build/probe/<hash>/fingerprint/dep-lib-probe, inside thebuildprune, so the guard holds today under both layouts. The READMEenv:block now recommendsCARGO_BUILD_FINGERPRINT: "content"to consumers, which turns content freshness genuinely on where it was inert — and that is guarded under v1 (.fingerprint) and under v2 (build) alike. No live claim left unguarded.Narrow pass — the citations are the code, so they were all checked
Every upstream citation verified against the GitHub API, not read back from the PR:
feat(config): Add build.fingerprint, merged 2026-08-222026-08-22T00:58:09Z; milestone 1.100.02026-08-18T03:17:50Z; milestone 1.100.0-Zbuild-dir-new-layout, cargo 1.91C-tracking-issueNice touch, probably unintentional:
e8cb624d5— the cargo build the measurements were taken on — is #17382's merge commit. The measurement was taken on the first nightly that could have shown the change.Upstream docs corroborate the mechanism:
doc.rust-lang.org/nightly/cargo/reference/unstable.htmldocumentsbuild.fingerprint, Type string, Default"mtime", EnvironmentCARGO_BUILD_FINGERPRINT, with the worked example being exactly[unstable] checksum-freshness = trueplus[build] fingerprint = "content"."Moved switches, not withdrawn" — reproduced here, not accepted. On
nightly-2026-08-25(= cargo 1.100.0-nightlye8cb624d5, the cited toolchain), scratch crate, content changed and mtime backdated:-Z checksum-freshness locate-project→ exit 0. Still accepted.Fresh probe v0.1.0.CARGO_BUILD_FINGERPRINT=content→ Cargo reportsDirty probe v0.1.0with the reason the prior compilation fingerprinted build inputs using mtime and this one used content, thenCompiling.Accepted-but-inert, confirmed — which is what makes the old measurement stop reproducing silently, exactly as the comments now say.
The in-place write through the shared inode,
cp -alclone, one env var apart:debug/build/probe/<hash>/fingerprint/dep-lib-probe,.../out/probe-<hash>.d,debug/libprobe.d.dfiles, and not the dep-info fingerprintSo the hazard is intact, in place, and the v2 path named in
cache-lib.shand in the selftest header is byte-for-byte the path Cargo actually writes.Layout v2 confirmed structurally: no
<profile>/.fingerprint, no<profile>/deps; per-unitbuild/<pkg>/<hash>/{fingerprint,out,run}/.The unknown-key claim ("safe to export unconditionally") holds:
CARGO_BUILD_FINGERPRINT=contentis ignored with no warning and no behaviour change on 1.93.1 stable, 1.97.1 stable and 1.96.0-nightly.The measurements. Same selection (
find -type d \( -name .fingerprint -o -name build \) -prune, plus*.d, plus.rustc_info.json), same crate shape (serde + serde_json + regex), built both ways here:Test integrity
The restored coverage is real, not structural.
checksum_freshness_probe()still settles the question by experiment — warm build, change content, backdate the mtime to@1000000000, rebuild, grep forFresh probe— never by asking the toolchain its version. The three-state split survives intact (answer codes0/3held clear of bash's own statuses), the not-measured branch still emits a::warning::and dumps both probe logs, and the case-3 reason string was correctly updated to say both switches were set.CARGO_BUILD_FINGERPRINTis unset alongside the gate on both non-answers, so a skipped run leaves no half-armed environment behind.The reporting-line fix is the right one and the bug it fixes was real:
fingerprint/.*dep-matches.fingerprint/<unit>/dep-*(v1) andbuild/<pkg>/<hash>/fingerprint/dep-*(v2) and matches neither.dfamily. Confirmed in this PR's own CI log, under v2, printingnote: this cargo DOES rewrite its dep-info fingerprint file in place under content freshnessdirectly beneath a control listing that shows the rewrite — the contradiction the old pattern produced.Sanity runs
shellcheck -x --source-path=scripts scripts/*.sh— clean, exit 0.bash scripts/selftest.shfrom committed state at5543101— all 6 suites passed. This machine'scargo +nightlyis 1.96.0-nightly (layout v1):mode: on, control mutates.fingerprint/probe-<hash>/dep-lib-probe, 4 assertions, shares 4 / owns 21.mode: on, 4 assertions, shares 2 / owns 22. That is the wide-pass proof that the coverage is restored in the running product and not only on the author's box..gitea/workflows/ci.yamlis a comment-only change — the whole hunk is#lines. Nothing in PR #13's gate is weakened or reordered.gitdan-actions#14
Accurate and well-scoped. Labels (
bug) were attached atomically — the label event timestamp equalscreated_atto the second (2026-08-27T00:45:32Z). Its load-bearing claim checks out: under v2 a compile unit writesbuild/probe/934ed46…/out/{libprobe-<hash>.rlib,.rmeta,probe-<hash>.d}while the build-script run unit writesbuild/probe/e151e7f…/out/gen.txt— two different hash directories, both namedout/, needing opposite treatment. Exactly as stated.Nits (do not gate the merge)
build/under v2" then enumerates seven. Two of them (CACHEDIR.TAG,.rustc_info.json) sit at thetarget/root rather than under<profile>/, which is presumably where the count comes from — worth a word, since the number is doing rhetorical work.Bottom line
The research is right, the citations are right, the mechanism reproduces on an independent run of the same toolchain, and the guard is honestly documented as accidental under v2. Fix the
README.md:558-563paragraph — a date and the corrected reading — and this is an approve.VERDICT: APPROVE-WITH-NITS
Re-review of
fa3cef5against my REQUEST-CHANGES at5543101. The finding is fixed. Nothing else moved:git diff 5543101..fa3cef5is README-only, and--name-only -- scripts .giteais empty, so the shellcheck and full-selftest runs I did at5543101still describe the shipped scripts byte-for-byte.The headline finding is resolved
README.md:558-568no longer asserts the retracted reading. It now reads:Dated, in the house style, and it does not overclaim — checked against what the suite actually does rather than against the sentence:
checksum_freshness_probe()still builds a throwaway crate, changes its content, backdates the mtime to@1000000000, rebuilds and greps forFresh probe. Never a version check. True.CHECKSUM_MODE = "on"(hardlink-clone-selftest.sh:341), and the branch that cannot measure is the one that emits::warning::and tails both probe logs. The clause is scoped to cannot measure, not to measured inactive, and that is exactly the branch that is loud. Precisely right rather than approximately right — which matters here, because a measured-INACTIVE skip is deliberately quiet and the sentence does not claim otherwise.fa3cef53prints=== checksum-freshness mode: on ===,note: this cargo DOES rewrite its dep-info fingerprint file in place under content freshness, andhardlink-clone-selftest: 4 assertions passed. The named toolchain is observed doing the named thing in the run attached to this PR.Prose parses. The nested parenthetical closes in the right place: the outer
(nightly so …opens,(787af2b8c 2026-08-25)opens and closes inside it, and… cannot measure)closes the outer, givingIt installs shellcheck and both a stable and a nightly Rust toolchain (…) and references no credentials; …. Balanced to depth 0, checked programmatically over the whole sentence, and the em-dash-then-semicolon structure reads.The rest of the checklist
shares 4 / owns 21(v1) andshares 2 / owns 22(v2). Both match observation: my local run under 1.96.0-nightly gave shares 4 / owns 21, and CI runs 2631 and 2634 both give shares 2 / owns 22.owner/repoprefix — zero matches, andPart of daniel/gitdan#62.is intact.fa3cef53e0,pull_request, conclusionsuccess; shellcheck ran, all 6 suites passed.claude; PR still non-draft, correct for a workflow-touching PR.no nightly,currently enables,restores it,buys nothing,is skipped): the only hits left areREADME.md:239(an unrelated sentence about the mtime restore), the already-corrected selftest table row atREADME.md:581, andhardlink-clone-selftest.sh:183's off-mode reason string, which is correct as written.Nits (still non-gating)
787af2b8cis a rustc commit identifying a toolchain whose cargo carries the behaviour. That is the identifier a reader would reproduce with (rustup toolchain install nightly-2026-08-25) and it matches #62's own convention, so it is the right choice — noting it only so nobody later "corrects" it to a cargo hash.target/root rather than under<profile>/, which is presumably where "five" comes from). Churning #14's body mid-review buys nothing. Fold the one-word fix into whichever PR eventually closes #14, where the enumeration will be re-derived anyway.Bottom line
The one thing that was wrong is right, it is dated and hedged in the same style as the rest of the PR, and the claim it makes is observed in the run attached to this PR rather than asserted. Ship it.