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
symlinked snapshot path, whose entries are stored under the resolved
directory) and exited 0, even when nothing matched. Each such path is
now named in a warning as soon as the file list is built, so it shows
even when the restore then stops on an error, and restore returns an
error after restoring the paths that do match. The restore summary
moved into finishRestore to keep Restore within the length limit.

Making a path through a symlink match is not part of this change.
Judgement call: when the restore itself fails, that error is returned.

Model: opus-5-5
This commit was merged in pull request #365.
This commit is contained in:
2026-10-13 23:14:22 +02:00
parent 37d525c322
commit 2c087be577
4 changed files with 262 additions and 25 deletions
+3 -1
View File
@@ -382,7 +382,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