Addresses the PR #100 review round 4.
- MEDIUM stale skip-cache entry after a slot transfer. adopt() set
owner[hash] = new buffer but left the previous owner's `written` entry
pointing at the same hash, breaking the invariant
`written[id] => owner[hash] == id`. Repro: A and B are duplicate buffers
on one path; A owns the slot; B adopts (recover-file); B is killed
without saving, which frees the slot and deletes the file. A is still
dirty, but its stale written[A] = (hash, revA) makes the next sweep call
it "unchanged since its last copy" --- silently unprotected until its
next edit. adopt() now drops any other buffer's written entry for that
hash. Verified the new test fails without the fix (sweep writes 0).
- MEDIUM autosave write failures were swallowed. write_private can fail
(ENOSPC, a permission change, a clobbered state dir), but the tick and
before-quit paths did `pcall(sweep)` and dropped the error. For a
data-protection feature that is the worst failure mode: the user keeps
working, believing edits are captured, while nothing is written. Both
paths now go through a reporting wrapper --- status line "autosave
FAILED: ... --- your work is NOT being protected" on every failing sweep,
each distinct fault logged once via pmacs.error. The quit path reports
too (a failure there means the quit is about to discard work that was
never written anywhere) and still never vetoes.
Tests (autosave_acceptance now 29):
adopting_clears_the_previous_owners_stale_skip_cache,
a_failing_sweep_is_reported_not_swallowed (plants a regular file where
autosave/ must be a directory, standing in for ENOSPC).
Gates: fmt + workspace clippy clean; lib 1499; crdt 1670; autosave 29 + 8
units; desktop 11; persistence 5; m7_8 5; GPU 58; git diff --check clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Levi Neuwirth
c80e00e799