4 Commits

Include renames

Author	SHA1	Message	Date
clawbot	5db2e920e5	Label the index cleanup totals as totals (closes #306) ... The summary printed by the local index cleanup before each backup gave, in brackets after each removed count, the number of snapshots, files, chunks or blobs left in the local index, worded "(N remain)", which read as incomplete or orphaned rows left over: removing the only incomplete snapshot printed "1 removed (1 remain)". Each line now labels that figure as the total of its kind left in the local index. Model: opus-5-5	2026-10-14 02:03:51 +02:00
clawbot	0d0368df81	Report unknown blob figures for a snapshot whose manifest cannot be read (closes #272) ... When remote info could not read a snapshot's manifest, the orphan figures were unknown but the snapshot's row still gave 0 blobs and 0 B, in the table and in --json. The row's blob count and blob size are now unknown, and null in --json. A directory with no manifest, as an interrupted backup leaves, still shows 0: the orphan figures count its blobs as orphaned, so it references none. The constant holding the "unknown" text is renamed from countUnknown to unknownText, since it now also stands for a size. Model: opus-5-5	2026-10-08 08:46:11 +02:00
clawbot	e161343eac	Speed up the vaultik and database package tests (closes #235) ... In the Dockerfile test phase, internal/vaultik spent 23.6s of 31.9s in 36 tests run one at a time. 24 of them were serial only because they call log.Initialize; they now call it before t.Parallel(), so the logger is replaced before any parallel test runs. The 12 still serial change the umask, TMPDIR, os.Stderr or time.Local. TestLargeDatasets took 8.4s of the 9.8s internal/database run by committing each of its 1,500 inserts on its own; it now makes them in one transaction. TestDedupOnlySnapshotRestores gives its second backup its own snapshot name instead of sleeping 1.1s for a new snapshot ID. Model: opus-5-5	2026-10-07 17:12:07 +02:00
clawbot	c355ef4d25	Report a prune count that could not be read as unknown, not 0 (closes #96) ... Prune read table row counts before and after to report how many orphaned files, chunks and blobs it removed, and discarded the error from every read. A failed query therefore reported as a count of 0, and the summary showed plausible wrong numbers. A count that cannot be read is now logged as a warning (on stderr, also under --json) and shown as "unknown"; a difference computed from an unknown count is itself unknown. 0 still means the table was empty. No --json document carries these counts, so none can show a false 0. model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)	2026-09-21 21:41:57 +02:00