Make snapshot remove fail for an unknown snapshot ID (closes #293)
check / check (push) Waiting to run
check / check (push) Waiting to run
snapshot remove never checked that the ID existed: it deleted nothing, reported the snapshot removed from the local database and from the destination store, and exited 0, under --json, --dry-run and --local-only too. It now looks the ID up in the local index and, only when that has no row and --local-only is not set, on the destination store; finding neither is an error. The command reports a removal from the local database only when the local index had the row, and remote_removed is true only when metadata was actually deleted. Judgement call: under --local-only the destination store is not consulted, so the snapshot must be in the local index. Model: opus-5-5
This commit is contained in:
@@ -255,8 +255,12 @@ manifest (the destination store may hold snapshots this host doesn't
|
||||
know about), which is what 'vaultik prune' does. On success the command
|
||||
prints the exact 'vaultik prune' invocation to run as a follow-up.
|
||||
|
||||
An ID that names no snapshot in the local index or on the destination
|
||||
store is an error.
|
||||
|
||||
Use --local-only to skip the remote half (e.g. when you want to forget a
|
||||
snapshot locally without touching the destination store).
|
||||
snapshot locally without touching the destination store); the snapshot
|
||||
must then be in the local index.
|
||||
|
||||
If the remote is unreachable, the local-database removal still completes
|
||||
and a warning is emitted; run 'vaultik snapshot remove <snapshot-id>' again
|
||||
|
||||
Reference in New Issue
Block a user