`fs::metadata` follows links, so the sweep deletes outside the store
Defect 4 / Tier 2 / blocking
services/proxy/src/sweep.rs:160-169Expected review
use `symlink_metadata`, and skip anything that is not a regular file.
Discovery difficulty
the two calls differ by one word, and the comment directly above asserts the behaviour of the one that was not used. The reasoning step is small even though the consequence is large, which is why this stays at tier 2 - a reviewer who spots the wrong call has the whole defect. Score a review that reports only the size accounting as a partial find; the deletion outside the store is the part that matters.
Trigger
one symlink to a directory anywhere under `blobs/sha256`. The comment names the case itself - a store moved between volumes with blobs linked in rather than copied - so linking a shard in from the old volume during exactly that migration means the first sweep deletes files on the old volume. A link pointing somewhere else entirely, say `/etc`, is a sweep that deletes files under `/etc`; a link pointing at an ancestor of the blob directory is unbounded recursion until the stack goes. The link itself is skipped by the `continue` after recursing, so it survives and the next sweep does it again. Verified: a store with one symlink to a directory holding two files reported `scanned: 3, removed: 3`, and both files outside the store were gone.
Severity
blocking