hardlink_clone_into's cp_rc guard is unpinned: removing it leaves every suite green #5

New Issue

2026-08-24T16:46:09Z

claude commented

2026-08-24 16:46:09 +00:00

Surfaced while mutation-testing
#4, and confirmed
pre-existing — it is not a regression from that PR.

Problem

hardlink_clone_into's torn-read detection rests on three checks. Two of them
are pinned by the suites; the third is not.

Removing the [ "$cp_rc" -eq 0 ] guard leaves every fixture suite green:

suite	with the guard removed
`seed-target-dir-selftest.sh`	30 assertions, pass
`publish-snapshot-selftest.sh`	24 assertions, pass
`prune-cache-selftest.sh`	37 assertions, pass

Verified on main as well (3/3 runs green), so nothing about the recent
scenario-8 rewrite introduced it. The other two checks are now properly
discriminated — mutating the inode-identity check reddens scenario 8a and
mutating the entry-count check reddens 8b, each and only each — which is what
makes this third one conspicuous by contrast.

Why it matters

cp_rc is the guard for the case where cp -al itself reports failure —
a partial clone the copy knew about, as opposed to the two silent tears the
other guards catch (a source replaced underneath, and a subtree unlinked from
the parent's listing before it was walked). It is the least exotic of the three
failure modes and the only one the tool tells you about directly.

An unpinned guard is one refactor away from being dropped without anything
going red, and this repo's scripts/selftest.sh is its only gate — there is
no CI here.

Ask

Add a scenario that pins it: make cp -al fail partway — a PATH stub returning
non-zero after copying some entries is the mechanism the suite already uses for
its other forced interleavings (prune-cache-selftest.sh:238, and
seed-target-dir-selftest.sh's seed_with_stub) — and assert the clone is
reported as torn rather than renamed into place.

Acceptance criteria

A scenario fails if [ "$cp_rc" -eq 0 ] is removed from
hardlink_clone_into, and passes with it. Demonstrate the red/green
explicitly rather than asserting it.
It must fail for its own reason: removing either of the other two guards
must leave it green, so the three are independently pinned.
The scenario asserts loudly if its stub never fires, in the style the
existing forced-interleaving scenarios use — a scenario that silently
degrades to a non-test is the failure mode #3 was filed about.
The scenario's comment states which property it pins.

Surfaced while mutation-testing [#4](https://gitdan.com/daniel/gitdan-actions/pulls/4), and confirmed **pre-existing** — it is not a regression from that PR. ## Problem `hardlink_clone_into`'s torn-read detection rests on three checks. Two of them are pinned by the suites; the third is not. Removing the `[ "$cp_rc" -eq 0 ]` guard leaves **every fixture suite green**: | suite | with the guard removed | |---|---| | `seed-target-dir-selftest.sh` | 30 assertions, pass | | `publish-snapshot-selftest.sh` | 24 assertions, pass | | `prune-cache-selftest.sh` | 37 assertions, pass | Verified on `main` as well (3/3 runs green), so nothing about the recent scenario-8 rewrite introduced it. The other two checks are now properly discriminated — mutating the inode-identity check reddens scenario 8a and mutating the entry-count check reddens 8b, each and only each — which is what makes this third one conspicuous by contrast. ## Why it matters `cp_rc` is the guard for the case where `cp -al` **itself reports failure** — a partial clone the copy knew about, as opposed to the two silent tears the other guards catch (a source replaced underneath, and a subtree unlinked from the parent's listing before it was walked). It is the least exotic of the three failure modes and the only one the tool tells you about directly. An unpinned guard is one refactor away from being dropped without anything going red, and this repo's `scripts/selftest.sh` is its **only** gate — there is no CI here. ## Ask Add a scenario that pins it: make `cp -al` fail partway — a PATH stub returning non-zero after copying some entries is the mechanism the suite already uses for its other forced interleavings (`prune-cache-selftest.sh:238`, and `seed-target-dir-selftest.sh`'s `seed_with_stub`) — and assert the clone is reported as torn rather than renamed into place. ## Acceptance criteria - [ ] A scenario fails if `[ "$cp_rc" -eq 0 ]` is removed from `hardlink_clone_into`, and passes with it. **Demonstrate the red/green explicitly** rather than asserting it. - [ ] It must fail for its own reason: removing either of the other two guards must leave it green, so the three are independently pinned. - [ ] The scenario asserts loudly if its stub never fires, in the style the existing forced-interleaving scenarios use — a scenario that silently degrades to a non-test is the failure mode #3 was filed about. - [ ] The scenario's comment states which property it pins.

claude added the bug label 2026-08-24 16:46:09 +00:00

claude referenced this issue from a commit

2026-08-24 17:04:38 +00:00

docs(readme): census the three concurrency-scenario shapes honestly

claude referenced this issue

2026-08-24 17:04:54 +00:00

test(seed): force scenario 8's interleaving instead of racing for it #4

claude referenced this issue from a commit

2026-08-24 18:26:33 +00:00

test(seed): pin the two unguarded terms of the torn-clone condition

claude referenced a pull request that will close this issue

2026-08-24 18:28:24 +00:00