--- name: disk-full-reds-as-lnk1318-pdb-error description: "A nearly-full C: reds builds as LNK1318 'Unexpected PDB error; LIMIT (12)' — reads as a corrupt PDB or toolchain fault; the tell is that traceable-reqs alone survives." metadata: node_type: memory type: reference originSessionId: 97bd4780-202d-4522-9abc-8ac75f327f07 modified: 2026-08-05T02:08:21.741Z --- **Measured 2026-08-04 (todlando, HFENDULEAM).** C: hit **0.44 GB free of 1862 GB**. A lane redded 6 of 7 legs with: ``` LINK : fatal error LNK1318: Unexpected PDB error; LIMIT (12) ``` on `spt.pdb`. It reads as a corrupt PDB or a broken toolchain. It is neither — it is the linker unable to grow a 333 MB PDB on a full disk. **Nothing in the failure text says "disk".** **The positive tell:** `traceable-reqs` exited 0 while build, units, clippy and drift all exited 101. traceable-reqs is the only leg that **never links**. A leg table where treqs alone survives is the disk's signature, not the lane's. Same family of suspicion for `os error 112` and any mysterious mid-build I/O red. **⚠ It is a positive tell, NOT a clearing test (hertz, same day).** Signature absent says *nothing*: - a full disk can red **before any link step** (rustc writing rlibs / incremental), so no LNK1318 appears at all and treqs is not uniquely the survivor; - treqs can red for its own reasons (a missing tag), erasing the signature while the disk is still the cause. So "my table doesn't look like that one" is not a clean bill of health. **The falsifier for "this red was the disk" is FREE SPACE AT THE TIME OF THE RUN** — not the shape of the leg table. **Standing gap on this box:** no rig or gate log records free space at run start, so "was the disk full" is unanswerable after the fact for every red already in hand. Any red produced while free space was under ~1 GB is **uninterpretable and must be re-run, not re-read** — same rule as [[intermittent-green-is-zero-information]]: a red under an unmeasured confound is not evidence about the lane in either direction. **Context for the size:** ~198 GB of cargo build caches across `.worktrees` pools produced this. Reaping finished lanes' target subtrees recovered it (0.44 -> ~60 GB). Teardown discipline is [[quoted-measurement-decays-when-you-mutate-the-subject]]-adjacent: classify OUTBOUND (junction vs real tree) before deleting, sweep INBOUND reparse points, check `CARGO_TARGET_DIR` (the env-var face leaves no directory entry a dir sweep can see), and report free-space delta rather than sum-of-file-lengths — the two disagreed by 8% on one reap. Kin: [[measure-the-box-before-the-instrument]], [[tool-claim-must-name-its-environment]], [[rig-inherits-the-defect-it-studies]]. --- **⚠ SECOND FACE, 2026-08-22 (todlando + doyle, same box).** The entry above records a disk that was ALREADY full. This one was a disk **being drained by the build that failed**, and it is the commoner shape: free went 135.44 GB -> under 5 GB while two lane pools built COLD (74.4 GB + 47.3 GB = ~122 GB of allocation), and `LNK1318: Unexpected PDB error; OK (0)` landed on the link of `spt` — the LAST and LARGEST artifact of the 74 GB pool that was itself eating the volume. A `cargo clean -p spt-net` then "fixed" it, which is a FALSE CONFIRMATION of a corrupt-artifact theory: by the retry the pool was already built, so the incremental space needed was a fraction. **The clean freed 664 MB and was never the cause of the recovery.** Note the variant text: `OK (0)` here, `LIMIT (12)` above. Same defect, different parenthetical — do not key recognition on the code. **Cost of not reading this file:** two agents re-derived the mechanism from scratch, ranked mspdbsrv-contention FIRST on a signature match, and designed a contention experiment that would have been confounded (run 1 had low disk AND contention; any rerun today has 130+ GB free, so a non-reproduction would have said nothing). doyle retracted it himself before firing. The rule he adopted — **free space goes in the FIRST LINE of any build-failure report, not in the controls** — is this file's own "standing gap" bullet, re-earned at full cost. **Tell that would have caught it in one command:** `df -h` / `(Get-PSDrive C).Free`. Neither of us ran it, not because it was hard but because nobody thought the resource was interesting.