Repository navigation
fix(backup): store media under media/<id>/<filename> so same-named files cannot overwrite each other - #4
Merged
Conversation
…les cannot overwrite each other 'trokky backup' wrote every media file to the archive as media/<original filename>. A zip tolerates duplicate entry names, so the archive appeared complete, but 'trokky restore' built a filename -> entry map where the last entry won and uploaded that one for every media id sharing the name. On the Cour des Comptes instance 94 of 662 filenames are shared between media ids. 86 are byte-identical copies, harmless; 8 names cover 84 ids that are different photos (Photo-de-famille.jpg x17, Vue-partielle-des-participants.jpg x24). A restore reported 942/942 with 0 failed and ~76 photos came back as the wrong image. Entries are now scoped by media id, and the manifest records each item's archivePath. Restore resolves the manifest path first, then the id-scoped layout, then the flat legacy layout — and when it has to fall back to a legacy entry that several ids share, it warns that the bytes may be wrong and that a fresh backup is needed. Old archives with collisions cannot be repaired: the overwritten bytes were never written.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
'trokky backup' wrote every media file to the archive as media/. A zip tolerates duplicate entry names, so the archive appeared
complete, but 'trokky restore' built a filename -> entry map where the last
entry won and uploaded that one for every media id sharing the name.
On one production instance 94 of 662 filenames are shared between media
ids. 86 are byte-identical copies, harmless; 8 names cover 84 ids that are
different photos (Photo-de-famille.jpg x17, Vue-partielle-des-participants.jpg
x24). A restore reported 942/942 with 0 failed and ~76 photos came back as the
wrong image.
Entries are now scoped by media id, and the manifest records each item's
archivePath. Restore resolves the manifest path first, then the id-scoped
layout, then the flat legacy layout — and when it has to fall back to a legacy
entry that several ids share, it warns that the bytes may be wrong and that a
fresh backup is needed. Old archives with collisions cannot be repaired: the
overwritten bytes were never written.