What was wrong:snapshot create --skip-errors --prune ran the post-backup prune even when files were skipped. By default the prune keeps only the latest snapshot of each name, so it deleted the previous snapshot, the only one still holding a file that had become unreadable, together with blobs only that snapshot referenced. With --keep-newer-than the same happened once that snapshot left the window.
What changed: the prune is skipped exactly when the run exits non-zero for entries --skip-errors could not read or list, using the count #381 added. The older snapshots are kept, a warning says the prune was skipped and why, and the run exits non-zero as before. A file removed during the run is not counted, so such a run still prunes. The README's --prune text and the flag's help say so.
The new tests cover a file --skip-errors could not read keeping the previous snapshot under --prune, and a file removed during the run still letting the prune run. The skipped file is changed before it becomes unreadable, because an unchanged file is not read again.
Judgement call: with several snapshot names, one skipped entry in any of them skips the prune for every name in the run, matching the issue's "when any file or directory was skipped".
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/382.
**What was wrong:** `snapshot create --skip-errors --prune` ran the post-backup prune even when files were skipped. By default the prune keeps only the latest snapshot of each name, so it deleted the previous snapshot, the only one still holding a file that had become unreadable, together with blobs only that snapshot referenced. With `--keep-newer-than` the same happened once that snapshot left the window.
**What changed:** the prune is skipped exactly when the run exits non-zero for entries `--skip-errors` could not read or list, using the count https://git.eeqj.de/sneak/vaultik/pulls/381 added. The older snapshots are kept, a warning says the prune was skipped and why, and the run exits non-zero as before. A file removed during the run is not counted, so such a run still prunes. The README's `--prune` text and the flag's help say so.
The new tests cover a file `--skip-errors` could not read keeping the previous snapshot under `--prune`, and a file removed during the run still letting the prune run. The skipped file is changed before it becomes unreadable, because an unchanged file is not read again.
Judgement call: with several snapshot names, one skipped entry in any of them skips the prune for every name in the run, matching the issue's "when any file or directory was skipped".
Model: opus-5-5
snapshot create --skip-errors --prune pruned even when files were
skipped, so by default it deleted the previous snapshot of that name,
the only one still holding a file that had become unreadable, along
with blobs only that snapshot referenced.
The prune is now skipped exactly when the run exits non-zero for
entries --skip-errors could not read or list: older snapshots are
kept, a warning says why, and the run still exits non-zero. A file
removed during the run does not count, so such a run still prunes.
The README's --prune text and the flag's help say so.
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 #382.
What was wrong:
snapshot create --skip-errors --pruneran the post-backup prune even when files were skipped. By default the prune keeps only the latest snapshot of each name, so it deleted the previous snapshot, the only one still holding a file that had become unreadable, together with blobs only that snapshot referenced. With--keep-newer-thanthe same happened once that snapshot left the window.What changed: the prune is skipped exactly when the run exits non-zero for entries
--skip-errorscould not read or list, using the count #381 added. The older snapshots are kept, a warning says the prune was skipped and why, and the run exits non-zero as before. A file removed during the run is not counted, so such a run still prunes. The README's--prunetext and the flag's help say so.The new tests cover a file
--skip-errorscould not read keeping the previous snapshot under--prune, and a file removed during the run still letting the prune run. The skipped file is changed before it becomes unreadable, because an unchanged file is not read again.Judgement call: with several snapshot names, one skipped entry in any of them skips the prune for every name in the run, matching the issue's "when any file or directory was skipped".
Model: opus-5-5
Review passed.
Model: opus-5-5
clawbot referenced this pull request2026-10-14 08:00:18 +02:00