Repository navigation
An empty --album matches every album, and trashing by album acts on all of them #38
Description
Symptom
find_album has the same empty-reference hole #30 closed in find_person, with a worse blast
radius, and two neighbouring defects that mean it cannot be fixed alone.
1. --album "" matches every album. An empty string survives QueryArgs::is_empty() — it is
Some(""), not None — so contains("") matches everything and a single-album library resolves
silently. That reaches:
imogen trash --album "$ALBUM"
with the variable unset: exit 0, and a library's worth of photographs in the trash. find_album also
does not trim, so " " behaves the same way.
2. album_or_create matches on Err(_). An ambiguous name therefore creates a duplicate
album rather than refusing. This is why the guard above cannot go in by itself: find_album("")
starting to refuse would make this path create an album literally named "".
3. The exact-name tier is not uniqueness-checked, and album names have no unique index. With two
albums called "Holiday", imogen trash --album Holiday picks whichever the server listed first.
Reproduction
imogen trash --album ""— or with an unset shell variable — against a library with one album.- Everything in that album is trashed, exit 0.
Expected
All three together:
find_albumtrims and refuses an empty or whitespace-only reference, before anything reaches the
wire.album_or_createdistinguishes "not found" from "ambiguous", and creates only on the first.- The exact-name shortcut is taken only when that whole name is unique, falling through to the
existing ambiguity refusal otherwise.
That third point has prior art worth reading: the same shortcut was attempted for people in the PR
closing #30 and reintroduced the bug it was closing, because names are not unique. Review caught
it as a blocker. Do not lift it unguarded.
Affected repos
Only this one. Nothing on the wire changes.
Context
Found by review while closing #30 and #32. Not fixed there because (2) means the guard cannot land
alone, and the three together are a different change from the people-lookup fix.
Related: imogen album update -d "new text" --clear-description is #32's contradiction in another
command — AlbumArgs::Update declares no conflicts_with. Worth fixing in the same pass since it is
the same shape.
Activity
File into an album by its whole name, or make that name
Keep the trim with the guard, and say which album is which
ergofobe commentedon Sep 16, 2026
Fixed by #42, merged as 4a3cc7a.
All three together, as the issue argued they had to be.
albums_fortrims the referenceand refuses an empty one before anything reaches the wire;
named_albumis the exact tierboth lookups share — an id, or a name exactly one album carries, so two called "Holiday"
are refused rather than resolved to whichever the server listed first — and
album_or_createnow acts only on that, creating for a name nothing carries andpropagating an ambiguity or a failed listing instead of treating every
Erras "not thereyet".
The exact-name shortcut is guarded the way #30's was, and the refusals name each album with
its id, since the names are what was ambiguous.
One thing changed from the issue's shape after review:
album_or_createdoes not use thepartial-name tier at all. Routing creation through it made a name impossible to have —
"Holiday" beside "Holiday 2024" and "Holiday 2025" was refused as ambiguous — and where it
did resolve it filed photographs into an album nobody named. Filing into an album is a
name, not a search.
Two findings from that review are filed rather than fixed here: #41 (
album update -dwith
--clear-description, the contradiction this issue's Context named) and #43 (album create ""writes a name no lookup can reach).Refuse an album name and a flag pair that cannot mean anything (#44)