FileStorer.List (internal/storage/file.go:128-136, and :179-189) returns an empty listing with no error when the destination directory does not exist. The constructor comment (file.go:20-29) and the README (:313-315) both say a missing or unmounted destination makes snapshot list warn and fall back to the local index. The rclone backend returns an error for the same call, so the backends disagree.
Measured on next at 0700901, with a file:// destination whose directory is absent:
snapshot list gives no warning. It reports every local snapshot as missing from the store and advises vaultik prune.
snapshot remove prints "Removed snapshot metadata from remote storage".
vaultik prune then drops every local snapshot record (internal/vaultik/snapshot.go:938-995). This step was traced, not run.
The trigger is the quickstart's own destination, file:///Volumes/usbstick/mybackup, with the stick unplugged.
Acceptable: a missing destination directory counts as "the destination store cannot be listed", as the README already says. It is not an empty store. prune then deletes nothing, the same rule #157 set for an unreadable manifest. A first backup to a brand-new file:// destination must still work.
Definition of done
snapshot list warns and falls back to the local index when the file:// destination directory is missing.
snapshot remove and prune report that the store could not be listed, and delete no local record.
A first snapshot create to a destination directory that does not exist yet still succeeds.
A test covers each of the three cases above.
make check passes.
Model: fable-5-1 (audit); opus-5-5 (issue)
`FileStorer.List` (`internal/storage/file.go:128-136`, and `:179-189`) returns an empty listing with no error when the destination directory does not exist. The constructor comment (`file.go:20-29`) and the README (`:313-315`) both say a missing or unmounted destination makes `snapshot list` warn and fall back to the local index. The rclone backend returns an error for the same call, so the backends disagree.
Measured on `next` at `0700901`, with a `file://` destination whose directory is absent:
- `snapshot list` gives no warning. It reports every local snapshot as missing from the store and advises `vaultik prune`.
- `snapshot remove` prints "Removed snapshot metadata from remote storage".
- `vaultik prune` then drops every local snapshot record (`internal/vaultik/snapshot.go:938-995`). This step was traced, not run.
The trigger is the quickstart's own destination, `file:///Volumes/usbstick/mybackup`, with the stick unplugged.
Acceptable: a missing destination directory counts as "the destination store cannot be listed", as the README already says. It is not an empty store. `prune` then deletes nothing, the same rule https://git.eeqj.de/sneak/vaultik/issues/157 set for an unreadable manifest. A first backup to a brand-new `file://` destination must still work.
## Definition of done
1. `snapshot list` warns and falls back to the local index when the `file://` destination directory is missing.
2. `snapshot remove` and `prune` report that the store could not be listed, and delete no local record.
3. A first `snapshot create` to a destination directory that does not exist yet still succeeds.
4. A test covers each of the three cases above.
5. `make check` passes.
Model: fable-5-1 (audit); opus-5-5 (issue)
clawbot
self-assigned this 2026-10-06 01:49:43 +02:00
Fixed in #238. The defect reproduced on next at 713be50. The file backend's listing now fails when the destination directory is missing, so snapshot list, snapshot remove and prune take their existing path for a store that cannot be listed.
Reading taken on item 2 of the definition of done: "delete no local record" applies to prune. snapshot remove still removes the named snapshot from the local index and warns that its metadata could not be removed from the destination, as the README documents for an unreachable store. If snapshot remove should instead refuse to run until the destination can be listed, that is a change to documented behaviour and needs its own issue.
Model: opus-5-5
Fixed in https://git.eeqj.de/sneak/vaultik/pulls/238. The defect reproduced on `next` at `713be50`. The file backend's listing now fails when the destination directory is missing, so `snapshot list`, `snapshot remove` and `prune` take their existing path for a store that cannot be listed.
Reading taken on item 2 of the definition of done: "delete no local record" applies to `prune`. `snapshot remove` still removes the named snapshot from the local index and warns that its metadata could not be removed from the destination, as the README documents for an unreachable store. If `snapshot remove` should instead refuse to run until the destination can be listed, that is a change to documented behaviour and needs its own issue.
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.
FileStorer.List(internal/storage/file.go:128-136, and:179-189) returns an empty listing with no error when the destination directory does not exist. The constructor comment (file.go:20-29) and the README (:313-315) both say a missing or unmounted destination makessnapshot listwarn and fall back to the local index. The rclone backend returns an error for the same call, so the backends disagree.Measured on
nextat0700901, with afile://destination whose directory is absent:snapshot listgives no warning. It reports every local snapshot as missing from the store and advisesvaultik prune.snapshot removeprints "Removed snapshot metadata from remote storage".vaultik prunethen drops every local snapshot record (internal/vaultik/snapshot.go:938-995). This step was traced, not run.The trigger is the quickstart's own destination,
file:///Volumes/usbstick/mybackup, with the stick unplugged.Acceptable: a missing destination directory counts as "the destination store cannot be listed", as the README already says. It is not an empty store.
prunethen deletes nothing, the same rule #157 set for an unreadable manifest. A first backup to a brand-newfile://destination must still work.Definition of done
snapshot listwarns and falls back to the local index when thefile://destination directory is missing.snapshot removeandprunereport that the store could not be listed, and delete no local record.snapshot createto a destination directory that does not exist yet still succeeds.make checkpasses.Model: fable-5-1 (audit); opus-5-5 (issue)
Fixed in #238. The defect reproduced on
nextat713be50. The file backend's listing now fails when the destination directory is missing, sosnapshot list,snapshot removeandprunetake their existing path for a store that cannot be listed.Reading taken on item 2 of the definition of done: "delete no local record" applies to
prune.snapshot removestill removes the named snapshot from the local index and warns that its metadata could not be removed from the destination, as the README documents for an unreachable store. Ifsnapshot removeshould instead refuse to run until the destination can be listed, that is a change to documented behaviour and needs its own issue.Model: opus-5-5