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
Plan, per the ruling above (options A and B both; a missing destination directory is an error for a file:// URL only). One PR on next.
B: a missing file:// destination directory is an error
The file:// backend never creates the destination directory itself. A write when it is missing fails with an error that names the directory and says to create it (or mount the volume). Subdirectories under it (blobs/..., metadata/...) are still created as needed.
snapshot create checks this before it scans, so it fails at once with a non-zero exit and writes nothing.
The check holds on every write, not only at the start: a destination removed part-way through a backup makes that backup fail instead of being recreated by the next upload (the defect hunt in #288 showed a backup then exiting 0 with a blob missing).
S3 and rclone are unchanged by this part.
A: a marker file at the destination root
The first backup to a destination writes a small marker object at its root before its first upload, on every backend. Its content is a fixed line of plain text saying the directory is a vaultik backup destination: no host name, paths or times. Name it plainly (suggested: vaultik-destination.txt).
When the local index holds at least one snapshot (the index is already bound to one storage_url, see EnsureStorageBinding) and the marker is missing, the destination is treated as not present: snapshot create refuses before writing anything, and prune, snapshot purge, snapshot remove and snapshot list behave as they do now for a destination that cannot be listed. The error names the destination and says: mount the volume if it is removable; if the destination was emptied on purpose, run vaultik database delete and back up again.
With no snapshots in the local index (a first backup, or restoring on another machine), nothing is checked.
remote nuke deletes the marker as its last step, once the local snapshot records are gone.
Docs: the README quickstart creates the destination directory before the first backup; the remote layout in the README and ARCHITECTURE.md lists the marker; the case of an unplugged volume is described where prune and snapshot list document a destination that cannot be listed.
Tests: a missing file:// directory fails snapshot create and creates nothing; a destination with local snapshots and no marker makes snapshot create, prune, snapshot purge, snapshot remove and snapshot list delete and write nothing; a first backup writes the marker; a backup after remote nuke succeeds.
Model: opus-5-5
Plan, per the ruling above (options A and B both; a missing destination directory is an error for a `file://` URL only). One PR on `next`.
**B: a missing `file://` destination directory is an error**
- The `file://` backend never creates the destination directory itself. A write when it is missing fails with an error that names the directory and says to create it (or mount the volume). Subdirectories under it (`blobs/...`, `metadata/...`) are still created as needed.
- `snapshot create` checks this before it scans, so it fails at once with a non-zero exit and writes nothing.
- The check holds on every write, not only at the start: a destination removed part-way through a backup makes that backup fail instead of being recreated by the next upload (the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 showed a backup then exiting 0 with a blob missing).
- S3 and rclone are unchanged by this part.
**A: a marker file at the destination root**
- The first backup to a destination writes a small marker object at its root before its first upload, on every backend. Its content is a fixed line of plain text saying the directory is a vaultik backup destination: no host name, paths or times. Name it plainly (suggested: `vaultik-destination.txt`).
- When the local index holds at least one snapshot (the index is already bound to one `storage_url`, see `EnsureStorageBinding`) and the marker is missing, the destination is treated as not present: `snapshot create` refuses before writing anything, and `prune`, `snapshot purge`, `snapshot remove` and `snapshot list` behave as they do now for a destination that cannot be listed. The error names the destination and says: mount the volume if it is removable; if the destination was emptied on purpose, run `vaultik database delete` and back up again.
- With no snapshots in the local index (a first backup, or restoring on another machine), nothing is checked.
- `remote nuke` deletes the marker as its last step, once the local snapshot records are gone.
**Docs:** the README quickstart creates the destination directory before the first backup; the remote layout in the README and `ARCHITECTURE.md` lists the marker; the case of an unplugged volume is described where `prune` and `snapshot list` document a destination that cannot be listed.
**Tests:** a missing `file://` directory fails `snapshot create` and creates nothing; a destination with local snapshots and no marker makes `snapshot create`, `prune`, `snapshot purge`, `snapshot remove` and `snapshot list` delete and write nothing; a first backup writes the marker; a backup after `remote nuke` succeeds.
Model: opus-5-5
sneak
was unassigned by clawbot2026-10-13 00:30:16 +02:00
clawbot
self-assigned this 2026-10-13 00:30:16 +02:00
Built in #349, as planned above: every backup writes vaultik-destination.txt; while the local index holds snapshots, a destination without it is treated as not present; the file:// backend never creates its destination directory. One reading beyond the plan: the marker is rewritten on every backup, not only the first.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/vaultik/pulls/349, as planned above: every backup writes `vaultik-destination.txt`; while the local index holds snapshots, a destination without it is treated as not present; the `file://` backend never creates its destination directory. One reading beyond the plan: the marker is rewritten on every backup, not only the first.
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.
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
B and A both. a missing dest directory is an error it it is a file: url. s3 obviously doesn’t have directories.
Plan, per the ruling above (options A and B both; a missing destination directory is an error for a
file://URL only). One PR onnext.B: a missing
file://destination directory is an errorfile://backend never creates the destination directory itself. A write when it is missing fails with an error that names the directory and says to create it (or mount the volume). Subdirectories under it (blobs/...,metadata/...) are still created as needed.snapshot createchecks this before it scans, so it fails at once with a non-zero exit and writes nothing.A: a marker file at the destination root
vaultik-destination.txt).storage_url, seeEnsureStorageBinding) and the marker is missing, the destination is treated as not present:snapshot createrefuses before writing anything, andprune,snapshot purge,snapshot removeandsnapshot listbehave as they do now for a destination that cannot be listed. The error names the destination and says: mount the volume if it is removable; if the destination was emptied on purpose, runvaultik database deleteand back up again.remote nukedeletes the marker as its last step, once the local snapshot records are gone.Docs: the README quickstart creates the destination directory before the first backup; the remote layout in the README and
ARCHITECTURE.mdlists the marker; the case of an unplugged volume is described wherepruneandsnapshot listdocument a destination that cannot be listed.Tests: a missing
file://directory failssnapshot createand creates nothing; a destination with local snapshots and no marker makessnapshot create,prune,snapshot purge,snapshot removeandsnapshot listdelete and write nothing; a first backup writes the marker; a backup afterremote nukesucceeds.Model: opus-5-5
Built in #349, as planned above: every backup writes
vaultik-destination.txt; while the local index holds snapshots, a destination without it is treated as not present; thefile://backend never creates its destination directory. One reading beyond the plan: the marker is rewritten on every backup, not only the first.Model: opus-5-5