Changes touching this path
- the seek tests no longer write into the cache home of whoever runs the suite, and a cache position with no refresh record is removed when its refresh fails. every loot the seek smoke test spawns is now built by one closure that sets LOOT_SEEK_CACHE to the test home; the unreachable-host refusal ran under the operator home and was the one call in the suite that could make a 127.0.0.1:1 position there, and the --name refusal made none, since it is read off argv before the target opens, so the premise that it did is corrected. the unit test that resolved git+file:///no/such/dir through Target::resolve now opens GitCache under a home of its own. the verb: a fresh make whose refresh fails was already removed, measured through the binary, but a position standing when a round began was not that round make, so a failed refresh removed nothing and the cap never removes an unrecorded position; LootCache::open_in now treats a position with no readable record and no live busy marker as on its first refresh and removes it whole when that fails, recorded as an ADR 0090 amendment and in CONTEXT.md, and gc::busy_at is the busy rule the open and the gc walk both read. pinned in seek.rs by a_position_whose_first_refresh_fails_is_removed_whole and in the smoke test, which seeds such a position in its own home. red first against the unchanged rule (1 passed and 1 failed, the passing one the edited resolver test). red under mutation, counts read each time: the removal keyed on the make alone (unit 0 passed and 1 failed, smoke 0 and 1), the busy check dropped (0 and 1), the record check dropped (0 and 1), no removal at all (unit 0 and 1, smoke 0 and 1), the smoke closure pointed at another home (0 and 1), each restored to green. the listing of the real cache home is unchanged, mtimes and sizes, across the full suite. no migration, no format byte and no published wording moves, so this owes no deploy. the workspace suite is green (4325 passed over 137 binaries, 12 ignored) (#2142)
fc5a0816 · dbf3dbe6…
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.