4 Commits

Include renames

Author	SHA1	Message	Date
clawbot	a0de8bfdb7	Refuse a backup destination an unplugged volume left empty (closes #239) ... Every backup writes vaultik-destination.txt at the destination root. While the local index holds snapshots stored there, a destination without it is not present: snapshot create refuses before writing, prune and snapshot purge fail, and snapshot list and snapshot remove act as for a destination that cannot be listed. snapshot create and snapshot remove check it first. remote nuke deletes the marker last. The file:// backend never creates its destination directory, which protects a directory on a removable volume, not a mount point. Tests back up into directories that exist; fixtures for a written destination carry the marker. Judgement call: the marker is rewritten on every backup. Deviation: for the complexity limit, two blocks moved, unchanged, into snapshotNamesToCreate and confirmRemoveSnapshot. Model: opus-5-5	2026-10-14 05:46:42 +02:00
clawbot	d156a02c49	Name each prefix once in restore, verify and purge errors (closes #327) ... A missing blob during restore, a failed shallow verify and an invalid purge duration each printed their prefix twice. FetchBlob now returns the storage error as is, since restore and deep verify name the blob themselves; purge returns the duration parser's error unchanged; and a failed shallow verify wraps "problems found in storage" instead of "verification failed", which the command already prints. Deep verify words a storage error other than not found as a blob it could not check, and its log line no longer says S3. Already fixed for #314: the deep verify size message naming S3 and other errors called missing; tests now check both. Not tested: the log line. Model: opus-5-5	2026-10-14 04:04:14 +02:00
clawbot	42eb50b151	Report blob counts from snapshot verify --deep --json (closes #314) ... Deep verify set verified only on success and never set missing, so a failed --deep --json run reported zero for both. It now counts each blob whose contents pass, and its existence check covers every blob, counting not-found ones as missing and wrong-size ones as mismatched, as shallow verify does; it fails if it found any. Any other storage error stops the check and fails with that error, so a blob that cannot be checked is never reported as missing. Deep verify still stops at the first damaged blob and reads no contents while any blob is missing or the wrong size, so verified is 0 there. Model: opus-5-5	2026-10-13 21:26:55 +02:00
clawbot	c423d13191	Hash the plaintext, not the encrypted bytes, in verify --deep (closes #131) ... The last step of verify --deep hashed the encrypted bytes it downloaded once with SHA256 and compared the result to the blob name. The name is the double SHA256 of the blob plaintext, so the two could never match and deep verification failed on every healthy blob with "blob hash mismatch". It now hashes the decompressed plaintext as chunk verification streams it and compares the double SHA256 of that to the blob name, the same derivation the writer uses. A new test backs up a real snapshot, runs deep verify on it, then flips one byte in a stored blob and expects failure. model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)	2026-09-21 20:24:37 +02:00