Question: how should vaultik tell an unplugged file:// volume from a new, empty destination?
#238 made a destination directory that does not exist count as "cannot be listed". snapshot list now warns, and prune deletes nothing. Two cases still look like an empty destination and act on it:
storage_url points at the mount point itself, for example file:///mnt/backups. When the volume is unplugged, an empty directory stays behind. It lists as an empty store, so prune drops every local snapshot record.
snapshot create runs while the volume is unplugged. It creates the destination directory under the empty mount point on the internal disk and writes the whole backup there. With --prune, the purge that follows then drops the older local snapshot records.
In both cases the data on the volume is untouched. What is lost is the local index records, and in case 2 the space on the internal disk.
Options
A (recommended): the first backup writes a small marker file at the destination root. If the local index already has snapshots for that destination and the marker is missing, every command treats the destination as not present: snapshot create refuses to write, and prune, snapshot remove and snapshot list behave as they do now for a store that cannot be listed. A destination with no snapshots in the local index is still created on the first backup.
B:snapshot create never creates the destination directory, so the user makes it once by hand. This fixes case 2 when the destination is a subdirectory of the mount point. It does not fix case 1.
C: change nothing in the code; the README says to point storage_url at a subdirectory of the mount point, never at the mount point itself.
Model: opus-5-5
**Question:** how should vaultik tell an unplugged `file://` volume from a new, empty destination?
https://git.eeqj.de/sneak/vaultik/pulls/238 made a destination directory that does not exist count as "cannot be listed". `snapshot list` now warns, and `prune` deletes nothing. Two cases still look like an empty destination and act on it:
1. `storage_url` points at the mount point itself, for example `file:///mnt/backups`. When the volume is unplugged, an empty directory stays behind. It lists as an empty store, so `prune` drops every local snapshot record.
2. `snapshot create` runs while the volume is unplugged. It creates the destination directory under the empty mount point on the internal disk and writes the whole backup there. With `--prune`, the purge that follows then drops the older local snapshot records.
In both cases the data on the volume is untouched. What is lost is the local index records, and in case 2 the space on the internal disk.
**Options**
- **A (recommended):** the first backup writes a small marker file at the destination root. If the local index already has snapshots for that destination and the marker is missing, every command treats the destination as not present: `snapshot create` refuses to write, and `prune`, `snapshot remove` and `snapshot list` behave as they do now for a store that cannot be listed. A destination with no snapshots in the local index is still created on the first backup.
- **B:** `snapshot create` never creates the destination directory, so the user makes it once by hand. This fixes case 2 when the destination is a subdirectory of the mount point. It does not fix case 1.
- **C:** change nothing in the code; the README says to point `storage_url` at a subdirectory of the mount point, never at the mount point itself.
Model: opus-5-5
sneak
was assigned by clawbot2026-10-06 08:46:47 +02:00
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.
Question: how should vaultik tell an unplugged
file://volume from a new, empty destination?#238 made a destination directory that does not exist count as "cannot be listed".
snapshot listnow warns, andprunedeletes nothing. Two cases still look like an empty destination and act on it:storage_urlpoints at the mount point itself, for examplefile:///mnt/backups. When the volume is unplugged, an empty directory stays behind. It lists as an empty store, soprunedrops every local snapshot record.snapshot createruns while the volume is unplugged. It creates the destination directory under the empty mount point on the internal disk and writes the whole backup there. With--prune, the purge that follows then drops the older local snapshot records.In both cases the data on the volume is untouched. What is lost is the local index records, and in case 2 the space on the internal disk.
Options
snapshot createrefuses to write, andprune,snapshot removeandsnapshot listbehave as they do now for a store that cannot be listed. A destination with no snapshots in the local index is still created on the first backup.snapshot createnever creates the destination directory, so the user makes it once by hand. This fixes case 2 when the destination is a subdirectory of the mount point. It does not fix case 1.storage_urlat a subdirectory of the mount point, never at the mount point itself.Model: opus-5-5