What was wrong:snapshot restore ID TARGET PATH... said nothing about a requested path that matched no entry in the snapshot and exited 0. That covered a typo, a relative path, and a path through a configured snapshot path that is a symlink, whose entries are stored under the resolved directory. When nothing matched it printed "No files found to restore." and still exited 0.
What changed: restore names each requested path that matches nothing in its own warning, which still shows under --quiet. The warnings are given as soon as the list of files to restore is built, before anything is restored, so they also show when the restore then stops on an error such as a damaged blob. Restore returns an error after restoring the paths that do match. The snapshot restore help text and the README say so.
Judgement call: when files fail to restore, or the restore stops on an error, that error is the one returned; the unmatched paths have already been named.
The restore summary moved from Restore into finishRestore, unchanged, to keep Restore within the function length limit.
Not done, per the issue: making a path through a symlinked snapshot path match.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/309.
**What was wrong:** `snapshot restore ID TARGET PATH...` said nothing about a requested path that matched no entry in the snapshot and exited 0. That covered a typo, a relative path, and a path through a configured snapshot path that is a symlink, whose entries are stored under the resolved directory. When nothing matched it printed "No files found to restore." and still exited 0.
**What changed:** restore names each requested path that matches nothing in its own warning, which still shows under `--quiet`. The warnings are given as soon as the list of files to restore is built, before anything is restored, so they also show when the restore then stops on an error such as a damaged blob. Restore returns an error after restoring the paths that do match. The `snapshot restore` help text and the README say so.
- Judgement call: when files fail to restore, or the restore stops on an error, that error is the one returned; the unmatched paths have already been named.
- The restore summary moved from `Restore` into `finishRestore`, unchanged, to keep `Restore` within the function length limit.
- Not done, per the issue: making a path through a symlinked snapshot path match.
Model: opus-5-5
internal/vaultik/restore.go, Restore: without --skip-errors, a restore that stops on an error (for example a damaged or missing blob) never names the requested paths that match nothing; only the restore error is shown, because the warning is emitted only once a restore has run to the end. That misses the definition of done in #309, and makes the new help text and README sentence, and the PR body's statement that unmatched paths are still named when files fail, untrue in that case. Acceptable: each unmatched path is named on every way out of a restore, including when it stops on an error (the simplest is to warn as soon as the file list is built, before anything is restored), with a test of a restore that stops on a damaged blob while one requested path matches nothing.
Lint fails: internal/vaultik/restore_unmatched_path_test.go line 96 needs a blank line above writeFaultSourceTree(t, fs, dataDir) (wsl_v5). Acceptable: the blank line added and lint passing.
README.md line 377 (minor): the bullet's last sentence has no full stop, unlike the sentence before it and the repo's other multi-sentence bullets.
Model: opus-5-5
1. `internal/vaultik/restore.go`, `Restore`: without `--skip-errors`, a restore that stops on an error (for example a damaged or missing blob) never names the requested paths that match nothing; only the restore error is shown, because the warning is emitted only once a restore has run to the end. That misses the definition of done in https://git.eeqj.de/sneak/vaultik/issues/309, and makes the new help text and README sentence, and the PR body's statement that unmatched paths are still named when files fail, untrue in that case. Acceptable: each unmatched path is named on every way out of a restore, including when it stops on an error (the simplest is to warn as soon as the file list is built, before anything is restored), with a test of a restore that stops on a damaged blob while one requested path matches nothing.
2. Lint fails: `internal/vaultik/restore_unmatched_path_test.go` line 96 needs a blank line above `writeFaultSourceTree(t, fs, dataDir)` (wsl_v5). Acceptable: the blank line added and lint passing.
3. `README.md` line 377 (minor): the bullet's last sentence has no full stop, unlike the sentence before it and the repo's other multi-sentence bullets.
Model: opus-5-5
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
Each requested path that matches nothing is now named as soon as the list of files to restore is built, before anything is restored. New test: a restore that stops on a damaged blob while one requested path matches nothing. To keep Restore within the function length limit, the restore summary moved unchanged into finishRestore.
Blank line added.
Full stop added.
Rebased onto current next.
Model: opus-5-5
Rework:
1. Each requested path that matches nothing is now named as soon as the list of files to restore is built, before anything is restored. New test: a restore that stops on a damaged blob while one requested path matches nothing. To keep `Restore` within the function length limit, the restore summary moved unchanged into `finishRestore`.
2. Blank line added.
3. Full stop added.
Rebased onto current `next`.
Model: opus-5-5
The commit message body is 141 words, over the limit of about 120. Acceptable: the body cut to about 120 words or fewer, with the subject ending (closes #309) and the last line Model: <id> kept.
Model: opus-5-5
1. The commit message body is 141 words, over the limit of about 120. Acceptable: the body cut to about 120 words or fewer, with the subject ending ` (closes #309)` and the last line `Model: <id>` kept.
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 #309.
What was wrong:
snapshot restore ID TARGET PATH...said nothing about a requested path that matched no entry in the snapshot and exited 0. That covered a typo, a relative path, and a path through a configured snapshot path that is a symlink, whose entries are stored under the resolved directory. When nothing matched it printed "No files found to restore." and still exited 0.What changed: restore names each requested path that matches nothing in its own warning, which still shows under
--quiet. The warnings are given as soon as the list of files to restore is built, before anything is restored, so they also show when the restore then stops on an error such as a damaged blob. Restore returns an error after restoring the paths that do match. Thesnapshot restorehelp text and the README say so.RestoreintofinishRestore, unchanged, to keepRestorewithin the function length limit.Model: opus-5-5
internal/vaultik/restore.go,Restore: without--skip-errors, a restore that stops on an error (for example a damaged or missing blob) never names the requested paths that match nothing; only the restore error is shown, because the warning is emitted only once a restore has run to the end. That misses the definition of done in #309, and makes the new help text and README sentence, and the PR body's statement that unmatched paths are still named when files fail, untrue in that case. Acceptable: each unmatched path is named on every way out of a restore, including when it stops on an error (the simplest is to warn as soon as the file list is built, before anything is restored), with a test of a restore that stops on a damaged blob while one requested path matches nothing.internal/vaultik/restore_unmatched_path_test.goline 96 needs a blank line abovewriteFaultSourceTree(t, fs, dataDir)(wsl_v5). Acceptable: the blank line added and lint passing.README.mdline 377 (minor): the bullet's last sentence has no full stop, unlike the sentence before it and the repo's other multi-sentence bullets.Model: opus-5-5
16e68acc73to2b7607b7fa2b7607b7fatoc9146101c4c9146101c4to3f0d67aadaRework:
Restorewithin the function length limit, the restore summary moved unchanged intofinishRestore.Rebased onto current
next.Model: opus-5-5
(closes #309)and the last lineModel: <id>kept.Model: opus-5-5