CoalWash v1.12.10 - a bin copy is named once whole; a future-dated item stops evicting

[github-actions[bot]]

A bin copy is named once whole; a future-dated item stops evicting

Two fixes to the recovery bins. Nothing is removed from the plugin and no command or config key changes. The installed plugin moved in four files (git diff --stat 8dc0efc HEAD -- plugin/: 4 files, 75 insertions, 14 deletions): the plugin/ twins of scripts/lib/tailings.mjs and scripts/lib/retention.mjs (git diff --stat 8dc0efc HEAD -- plugin/scripts/lib/: 2 files, 73 insertions, 12 deletions), the size-cap line of skills/coalwash/references/method.md and its twin's copy of it, and the version in plugin.json.

Fixed

• A recovery copy that was cut short is never listed as a whole one (E1 t173). A copy was written straight under its final name, so a CoalWash process killed mid-write left a truncated file under that name; since v1.12.9 such a file was listed and restore printed it as complete. writeBlobWhole (scripts/lib/tailings.mjs) now writes the bytes to a temporary name in the bin folder (<id>.<12 hex>.part, a shape loadIndex never lists), syncs it, and only then names the copy with a hard link to its id; an id that already exists is still a refusal, so nothing is written through or over an entry already there. removeStaleTemps removes a temporary file a killed writer left behind during the next wash, inside the bin lock: only that name pattern, only plain files, only after the lock's 5-second stale window, each named in the bin's death log; a bin holding only such a file is still swept. On a filesystem without hard links (NO_HARD_LINKS: EPERM, ENOTSUP, EOPNOTSUPP, ENOSYS and EISDIR, the code a Windows FAT or exFAT volume answers a hard link with) the copy is still written directly under its final name, the old behaviour, so a writer killed mid-write there can still leave a truncated copy that is listed. Tests in scripts/lib/tailings.test.mjs: E1 t173: a writer killed after writing its copy but before naming it leaves nothing in the catalogue; its unfinished temp is never listed; E1 t173: the next sweep removes a dead writer's temp older than the stale window, and only that: a fresh temp, a folder in the temp shape and other names stay; E1 t173: a recorded copy is named by its id alone: no temp is left and the copy has one link; E1 t173: on a filesystem without hard links the copy is written at its id directly, whole, and no temp is left; E1 t173: a link refused because the id name already exists records nothing (no write through or over that entry) and leaves no temp; INSPECT 114 R114-1: a Windows FAT or exFAT volume answers EISDIR for a hard link, and the copy is still written at its id directly.
• A bin item with a future or unreadable date no longer pushes real copies out under the size cap (INSPECT 109). Such an item is kept and never evicted, but its size still counted against the cap, so one planted future-dated row or copy could evict genuine recovery copies to make room for it. In scripts/lib/retention.mjs it now weighs nothing in the cap total, the same rule the eviction side already used, so the unreachable-cap line (capConflict) no longer counts its bytes either. Tests: INSPECT 109: a doubt item (a future or unreadable time) weighs nothing in the size cap, so a real past-floor copy is never evicted to make room for it in scripts/lib/tailings.test.mjs, and 0i size-cap fail direction: weightless (no/zero bytes) and doubt (future at) items are NEVER size-evicted; the unreachable cap is REPORTED in scripts/lib/retention-policy.test.mjs (its expected keptBytes moves from 900 to 400, the doubt weight removed).

---

Release page · CoalWash