vaultik

324 Commits 20 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
clawbot	0d0368df81	Report unknown blob figures for a snapshot whose manifest cannot be read (closes #272 ) check / check (push) Canceled after 0s Details 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 ) check / check (push) Canceled after 0s Details 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 ) check / check (pull_request) Failing after 1s Details check / check (push) Successful in 2m46s Details 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

Author

SHA1

Message

Date

clawbot

0d0368df81

Report unknown blob figures for a snapshot whose manifest cannot be read (closes #272 )

check / check (push) Canceled after 0s

Details

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 )

check / check (push) Canceled after 0s

Details

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 )

check / check (pull_request) Failing after 1s

Details

check / check (push) Successful in 2m46s

Details

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