What was wrong:snapshot restore and snapshot verify --deep read the snapshot database straight from storage (downloadSnapshotDB in restore.go, downloadVerifiedSnapshotDB in verify.go), not through FetchBlob, so the fix in #355 did not reach that read. When it stalled on a slow USB stick or network share, Ctrl-C could not end it: the process exited at the shutdown timeout without its cleanup and left the decrypted database in the temp directory.
What changed: both functions now wrap the storage reader in the same closeOnCancelReader that FetchBlob uses, so a cancel closes it, the read ends with the context's error, and the temp directory is removed.
The interrupt test added for #325 now stalls either a blob read or the snapshot database read, each during restore and during deep verify; its storer takes the keys to stall as a parameter. Most of the test diff is re-indentation from the added loop; git diff -w shows the real change.
The test waits for the scratch files to appear instead of checking at once: the database's temp directory is created only after its read has begun, so it can appear just after the stall.
Limitation: a read stuck in the kernel that closing cannot interrupt (an unresponsive hard NFS mount) still cannot be stopped.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/356.
**What was wrong:** `snapshot restore` and `snapshot verify --deep` read the snapshot database straight from storage (`downloadSnapshotDB` in `restore.go`, `downloadVerifiedSnapshotDB` in `verify.go`), not through `FetchBlob`, so the fix in https://git.eeqj.de/sneak/vaultik/pulls/355 did not reach that read. When it stalled on a slow USB stick or network share, Ctrl-C could not end it: the process exited at the shutdown timeout without its cleanup and left the decrypted database in the temp directory.
**What changed:** both functions now wrap the storage reader in the same `closeOnCancelReader` that `FetchBlob` uses, so a cancel closes it, the read ends with the context's error, and the temp directory is removed.
The interrupt test added for https://git.eeqj.de/sneak/vaultik/issues/325 now stalls either a blob read or the snapshot database read, each during restore and during deep verify; its storer takes the keys to stall as a parameter. Most of the test diff is re-indentation from the added loop; `git diff -w` shows the real change.
- The test waits for the scratch files to appear instead of checking at once: the database's temp directory is created only after its read has begun, so it can appear just after the stall.
- Limitation: a read stuck in the kernel that closing cannot interrupt (an unresponsive hard NFS mount) still cannot be stopped.
Model: opus-5-5
Restore and deep verify read the snapshot database straight from
storage rather than through FetchBlob, so the earlier fix for stalled
blob reads did not cover it. A database read stalled on a slow USB
stick or network share kept the operation from returning after Ctrl-C;
the process then exited at the shutdown timeout and left the decrypted
database in the temp directory.
Both reads now wrap the storage reader in the close-on-cancel reader
FetchBlob uses, so a cancel ends the stalled read and the temp
directory is removed. The interrupt test now stalls either a blob or
the snapshot database, for both commands.
Limitation: a read stuck in the kernel that closing cannot interrupt,
such as one on an unresponsive hard NFS mount, still cannot be stopped.
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 #356.
What was wrong:
snapshot restoreandsnapshot verify --deepread the snapshot database straight from storage (downloadSnapshotDBinrestore.go,downloadVerifiedSnapshotDBinverify.go), not throughFetchBlob, so the fix in #355 did not reach that read. When it stalled on a slow USB stick or network share, Ctrl-C could not end it: the process exited at the shutdown timeout without its cleanup and left the decrypted database in the temp directory.What changed: both functions now wrap the storage reader in the same
closeOnCancelReaderthatFetchBlobuses, so a cancel closes it, the read ends with the context's error, and the temp directory is removed.The interrupt test added for #325 now stalls either a blob read or the snapshot database read, each during restore and during deep verify; its storer takes the keys to stall as a parameter. Most of the test diff is re-indentation from the added loop;
git diff -wshows the real change.Model: opus-5-5
Review passed.
Model: opus-5-5