Fail restore for a requested path that matches nothing (closes #309)
check / check (push) Waiting to run

snapshot restore said nothing about a requested path that matched no
entry in the snapshot (a typo, a relative path, or a path through a
configured snapshot path that is a symlink, whose entries are stored
under the resolved directory) and exited 0, also when nothing matched
at all. Each such path is now named in a warning as soon as the list
of files to restore is built, so the names show even when the restore
then stops on an error, and restore returns an error after restoring
the paths that do match.

Making a path through a symlink match is not part of this change.
Judgement call: when files fail to restore or the restore stops on an
error, that error is the one returned.
The restore summary moved into finishRestore to keep Restore within
the function length limit.

Model: opus-5-5
This commit is contained in:
2026-10-13 20:14:50 +00:00
parent 5d8c515192
commit 3f0d67aada
4 changed files with 262 additions and 25 deletions
+3 -1
View File
@@ -373,7 +373,9 @@ on the destination in one go, use `vaultik remote nuke --force`.
store — its remote key (or an unambiguous leading part of it) as shown
by `snapshot list`. See
[restoring on another machine](#restoring-on-another-machine).
* Optional path arguments to restore specific files/directories (default: all)
* Optional path arguments to restore specific files/directories (default: all).
A path that matches nothing in the snapshot is named in a warning, and the
command exits non-zero after restoring the paths that match.
* Preserves file permissions, timestamps, ownership (ownership requires root),
symlinks, and empty directories
* `--verify`: After restoring, verify every restored file's chunk hashes