What is wrong: when metadata/ or blobs/ in a file:// destination is a symlink whose target is gone (for example, it points to another disk that is not mounted), the file backend's List and ListStream (internal/storage/file.go) treat it like a missing directory under an existing destination and return an empty listing. With metadata/ dangling, prune then drops every local snapshot record and deletes every blob as unreferenced. The marker planned in #239 does not catch this, because the destination root is present.
Definition of done
A file:// listing fails, instead of returning an empty listing, when metadata/ or blobs/ is a symlink whose target is missing; prune, snapshot list and remote nuke then take their existing path for a destination that cannot be listed.
A truly absent metadata/ or blobs/ directory under an existing destination still lists as empty.
A test shows prune deletes nothing with a dangling metadata/ symlink.
Model: opus-5-5
Found while fixing https://git.eeqj.de/sneak/vaultik/issues/296.
**What is wrong:** when `metadata/` or `blobs/` in a `file://` destination is a symlink whose target is gone (for example, it points to another disk that is not mounted), the file backend's `List` and `ListStream` (`internal/storage/file.go`) treat it like a missing directory under an existing destination and return an empty listing. With `metadata/` dangling, `prune` then drops every local snapshot record and deletes every blob as unreferenced. The marker planned in https://git.eeqj.de/sneak/vaultik/issues/239 does not catch this, because the destination root is present.
**Definition of done**
- A `file://` listing fails, instead of returning an empty listing, when `metadata/` or `blobs/` is a symlink whose target is missing; `prune`, `snapshot list` and `remote nuke` then take their existing path for a destination that cannot be listed.
- A truly absent `metadata/` or `blobs/` directory under an existing destination still lists as empty.
- A test shows `prune` deletes nothing with a dangling `metadata/` symlink.
Model: opus-5-5
Covered by the rework of #331: its review found this case inside the definition of done of #296.
Model: opus-5-5
Covered by the rework of https://git.eeqj.de/sneak/vaultik/pulls/331: its review found this case inside the definition of done of https://git.eeqj.de/sneak/vaultik/issues/296.
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.
Found while fixing #296.
What is wrong: when
metadata/orblobs/in afile://destination is a symlink whose target is gone (for example, it points to another disk that is not mounted), the file backend'sListandListStream(internal/storage/file.go) treat it like a missing directory under an existing destination and return an empty listing. Withmetadata/dangling,prunethen drops every local snapshot record and deletes every blob as unreferenced. The marker planned in #239 does not catch this, because the destination root is present.Definition of done
file://listing fails, instead of returning an empty listing, whenmetadata/orblobs/is a symlink whose target is missing;prune,snapshot listandremote nukethen take their existing path for a destination that cannot be listed.metadata/orblobs/directory under an existing destination still lists as empty.prunedeletes nothing with a danglingmetadata/symlink.Model: opus-5-5
Covered by the rework of #331: its review found this case inside the definition of done of #296.
Model: opus-5-5