main's #1240 landed the manifest lookup in its first form; the hardening that
followed only ever reached stable, via #1243. So main still silently loses
every category when restoring an archive written while
general_use_original_filenames_for_downloads was on: archiveService names
each ZIP entry after the ORIGINAL filename while the manifest stays keyed by
the internal photos.filename, so the lookup misses every entry.
Ported as one unit rather than piecemeal, since a third variant of this
function helps nobody:
- index by original_filename, and by sanitizeForZipEntry(original_filename)
as the ZIP would actually have written it
- two passes, canonical names claimed before any alias, so the result no
longer depends on manifest iteration order (the archive query has no
ORDER BY)
- a name two rows both claim is dropped rather than guessed — including the
canonical/alias clash, where which file the ZIP emitted depends on a
naming mode the manifest does not record
- globals count as existing, event-scoped rows win over them, and the global
arm requires event_id IS NULL so one event's legacy row can't be adopted by
another event's restore
- an invented category is explicitly is_global false; the column defaults to
TRUE, so a restore was leaking this event's naming into every gallery
- categories resolve inside the !existingPhoto branch, so a restore that
skips its inserts stops creating unused rows from stale manifest names
- a duplicate category name is logged and resolved by lowest id instead of
engine order
main-only code is untouched: the face-data cleanup (#1074, #1132) and the
uploaded_at toISOString fix both survive — stable still has the bare
new Date() there, which is the documented Jest/SQLite landmine and worth a
separate look.
15 tests, ported from #1243.
Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>
Paul Nothaft
a35d2bad66