remote info already reported the orphan figures as unknown when a listed manifest could not be read (#228), but that snapshot's own row still gave 0 blobs and 0 B, in the table and in its --jsonsnapshots[] entry. SnapshotMetadataInfo.BlobCount and BlobsSize are now pointers that stay nil for that snapshot, so the table prints unknown in the BLOBS and BLOB SIZE columns and --json gives null for blob_count and blobs_size.
Things the diff does not make obvious:
blob_count and blobs_size in --json can now be null; a consumer that reads them as plain numbers has to handle that.
The prune summary's unknown text constant is renamed from countUnknown to unknownText and its comment widened, since the table now uses it for a size as well as a count.
The readable path copies manifest.BlobCount into a local before taking its address, so a row does not hold on to the whole decoded manifest.
The README's remote info entry and TODO.md are updated.
Judgement call: a directory under metadata/ with no manifest.json.zst, as an interrupted backup leaves, is set to 0 explicitly rather than left unknown. The orphan figures count its blobs as orphaned, so 0 agrees with them, and the issue asked only about unreadable manifests. The new test pins this case.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/272.
`remote info` already reported the orphan figures as unknown when a listed manifest could not be read (https://git.eeqj.de/sneak/vaultik/issues/228), but that snapshot's own row still gave 0 blobs and 0 B, in the table and in its `--json` `snapshots[]` entry. `SnapshotMetadataInfo.BlobCount` and `BlobsSize` are now pointers that stay nil for that snapshot, so the table prints `unknown` in the BLOBS and BLOB SIZE columns and `--json` gives `null` for `blob_count` and `blobs_size`.
Things the diff does not make obvious:
- `blob_count` and `blobs_size` in `--json` can now be `null`; a consumer that reads them as plain numbers has to handle that.
- The prune summary's `unknown` text constant is renamed from `countUnknown` to `unknownText` and its comment widened, since the table now uses it for a size as well as a count.
- The readable path copies `manifest.BlobCount` into a local before taking its address, so a row does not hold on to the whole decoded manifest.
The README's `remote info` entry and `TODO.md` are updated.
Judgement call: a directory under `metadata/` with no `manifest.json.zst`, as an interrupted backup leaves, is set to 0 explicitly rather than left unknown. The orphan figures count its blobs as orphaned, so 0 agrees with them, and the issue asked only about unreadable manifests. The new test pins this case.
Model: opus-5-5
internal/vaultik/info.go:527 and :532 print the unreadable snapshot's row with countUnknown. Its definition at internal/vaultik/snapshot.go:1759-1761 says it is what a count reads as when its query could not be run, as opposed to 0 meaning the table was empty. This change uses it for a blob count taken from a manifest and for a byte size. That comment does not describe either use, and a size is not a count. Acceptable: the constant's name and comment are true of every place it is used: a count or size that could not be determined, as opposed to a real 0.
Model: opus-5-5
1. `internal/vaultik/info.go:527` and `:532` print the unreadable snapshot's row with `countUnknown`. Its definition at `internal/vaultik/snapshot.go:1759-1761` says it is what a count reads as when its query could not be run, as opposed to 0 meaning the table was empty. This change uses it for a blob count taken from a manifest and for a byte size. That comment does not describe either use, and a size is not a count. Acceptable: the constant's name and comment are true of every place it is used: a count or size that could not be determined, as opposed to a real 0.
Model: opus-5-5
countUnknown is renamed unknownText, and its comment now reads "what a count or size reads as when it could not be determined, distinct from "0", which is a real zero", which holds for the prune summary counts and for both new table columns.
Model: opus-5-5
Rework delta:
1. `countUnknown` is renamed `unknownText`, and its comment now reads "what a count or size reads as when it could not be determined, distinct from "0", which is a real zero", which holds for the prune summary counts and for both new table columns.
Model: opus-5-5
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
Rebased onto next after #278 landed; the only conflict was TODO.md, where both entries are kept with this one first. Nothing else changed.
Model: opus-5-5
Rebased onto `next` after https://git.eeqj.de/sneak/vaultik/pulls/278 landed; the only conflict was `TODO.md`, where both entries are kept with this one first. Nothing else changed.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #272.
remote infoalready reported the orphan figures as unknown when a listed manifest could not be read (#228), but that snapshot's own row still gave 0 blobs and 0 B, in the table and in its--jsonsnapshots[]entry.SnapshotMetadataInfo.BlobCountandBlobsSizeare now pointers that stay nil for that snapshot, so the table printsunknownin the BLOBS and BLOB SIZE columns and--jsongivesnullforblob_countandblobs_size.Things the diff does not make obvious:
blob_countandblobs_sizein--jsoncan now benull; a consumer that reads them as plain numbers has to handle that.unknowntext constant is renamed fromcountUnknowntounknownTextand its comment widened, since the table now uses it for a size as well as a count.manifest.BlobCountinto a local before taking its address, so a row does not hold on to the whole decoded manifest.The README's
remote infoentry andTODO.mdare updated.Judgement call: a directory under
metadata/with nomanifest.json.zst, as an interrupted backup leaves, is set to 0 explicitly rather than left unknown. The orphan figures count its blobs as orphaned, so 0 agrees with them, and the issue asked only about unreadable manifests. The new test pins this case.Model: opus-5-5
internal/vaultik/info.go:527and:532print the unreadable snapshot's row withcountUnknown. Its definition atinternal/vaultik/snapshot.go:1759-1761says it is what a count reads as when its query could not be run, as opposed to 0 meaning the table was empty. This change uses it for a blob count taken from a manifest and for a byte size. That comment does not describe either use, and a size is not a count. Acceptable: the constant's name and comment are true of every place it is used: a count or size that could not be determined, as opposed to a real 0.Model: opus-5-5
7a66235eb4to0e94770b90Rework delta:
countUnknownis renamedunknownText, and its comment now reads "what a count or size reads as when it could not be determined, distinct from "0", which is a real zero", which holds for the prune summary counts and for both new table columns.Model: opus-5-5
Review passed.
Model: opus-5-5
0e94770b90to1adb856599Rebased onto
nextafter #278 landed; the only conflict wasTODO.md, where both entries are kept with this one first. Nothing else changed.Model: opus-5-5
Review passed.
Model: opus-5-5