---
name: length-sum-over-a-cargo-target-double-counts-hardlinks
description: Get-ChildItem | Measure-Object Length over a cargo target/ overstates it ~15% because hardlinked pairs are summed twice; du deduplicates. Census by Length ranks pools, it does not predict reclaim.
metadata:
  type: feedback
---

2026-09-08, golden #272 r2 disk-floor triage. My pool census (PowerShell sum of file
Lengths under `.worktrees/*/target`) read shape-0680 at 11.57 GiB; deployah's `du -sh`
read 9.9G three minutes earlier. I explained the gap as allocated-vs-logical bytes.
Deployah MEASURED it: allocated vs apparent on that pool differs 0.24%, compression ratio
1.0, file counts identical (12852 both tools), zero reparse points; 5160 files with
nlink > 1 hold 3.48 GiB, and HALF of that predicts the 1.87 GB gap to 0.03%. Cargo target
dirs are hardlink-dense by construction (deps/ and the top-level artifact are one file with
two entries), so a Length sum counts each pair twice. Overstatement was 15.1% on the one
pool measured.

**Why:** a figure produced for ranking got quoted as "184 GB of reclaim". The post-reap
free-space reading was the real acceptance number and was safe by construction, but the
prediction was not, and my stated mechanism for the discrepancy was a guess dressed as an
explanation. Two tools disagreeing by more than a rounding error have a MECHANISM, and
the mechanism is measured (count nlink>1, compare apparent vs allocated), not named.

**How to apply:** for reclaim predictions on any target/, use `du --apparent-size` (Git
Bash has it) or accept only the post-reap free-space reading. Keep Length-sum censuses for
RANKING. When two measurements of one thing differ, test the first explanation before
sending it; "either alone covers it" without a number is the tell. See
[[a-column-that-reads-one-value-on-every-row-is-a-broken-extractor]] and
[[test-profile-pool-outgrows-the-disk-floor]].