Changes touching this path
- the file-holding test aggressors hold until the caller drops a guard instead of ending on a sleep: hold_without_share_delete in loot-core testkit and its copies in loot-identity and the loot-net mailbox return a guard whose drop ends the hold and waits for the handle to close, with an optional bound for an arm that asserts a wait, since the call under test holds the calling thread until it returns. the bare arms that assert a refusal now hold until their assertions are done, where a hold ending on a 60 ms sleep failed lands when the calling thread reached its operation after it; the retrying arms, and the store.rs atomic_write reader pin, which now takes the testkit helper, keep a bound inside the retry budget. the loot-identity archive refusal keeps its bound, so a retrying archive still outwaits it, and runs again on a fresh repo when a round succeeds, failing once 4 rounds have succeeded. with a 200 ms sleep after the hold standing in for a descheduled caller, the old helpers went 0 passed and 2 failed over the two loot-core refusal pins and 0 passed and 1 failed over the second-rename identity pin, with the sighted messages, and the guarded ones 2 passed and 1 passed. red under named mutations, each restored, 0 passed and 1 failed each time: the retrying arm unbounded, the retrying arm put back to a bare rename, the removal helper arm unbounded, the removal helper arm put back to a bare remove_file, the signal ignored for the old 60 ms sleep with the caller late in the testkit, persist_codec and second-rename refusal pins, the mailbox index hold unbounded, the store.rs reader hold unbounded, a retry loop given to the archive, and every archive round late; a late first round stays green. the scanner holds in persist_codec and the mailbox keep their timed release, since the save they hold up cannot finish before their hold ends. cargo test green, 4863 passed over 144 test result lines with 15 ignored. owes no deploy. it also files kmsukvmw, a key filed between a lane materialize and its next capture turning the paths it skipped into deletions, which a pull-grants during a land showed, and carries a comment on wvyrkooo (zvwxuszz)
916bf7bf · 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.