Repository navigation
Conversation
A zip that holds a pack in the device's own layout — ni, ri, si and the asset folders, as copied off an SD card — was handed to the archive reader on upload, which found no story.json, and the pack was silently dropped from the listing. The library reads that layout already, but only as a folder. The upload now unpacks such a zip into a folder of the library and does not keep the zip. The folder takes the name of the zip's single top-level folder when there is one, since FsStoryPackReader takes the pack's UUID from the folder name, and the upload's own name otherwise. Unpacking happens in the work folder first: an entry that would land outside the pack folder is refused, and nothing reaches the library. A zip with a story.json, or one the library does not recognise, is stored as it was — saving a pack from the editor goes through the same upload. Closes #22
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.
What
A zip that holds a pack in the device's own layout —
ni,ri,siand therf//sf/asset folders, as copied straight off an SD card — was handed to the archive reader on upload, which found nostory.json, and the pack was silently dropped from the listing. The library reads that layout already (FsStoryPackReader, including v2-ciphered packs), but only as a folder.The upload now unpacks such a zip into a folder of the library and does not keep the zip.
How
FsPackZipImporter(new): recognises the layout by content —story.json→ not ours;ni+ri+siat the root or under a single top-level folder → pack folder; anything else → not ours. Unpacks under a target, refusing any entry that would land outside it.LibraryService.addPackFile: when the upload is such a zip, unpacks it in the work folder first, then replaces/moves it into the library as<folder>/. The folder name is the zip's top-level folder when there is one (the reader takes the pack's UUID from the folder name), the upload's own name minus.zipotherwise. Both go through the existinglibraryEntryconfinement.Tests
LibraryFsPackImportTest, 6 specifications: unpacked under the folder's name / under the upload's name, archive stored unchanged, unknown zip stored unchanged, zip-slip entry refused with nothing written and the file outside untouched, existing folder replaced rather than merged into.Full Java suite: 315 tests, 0 failures. Verified by hand with a real v2 pack zipped off a device: listed as
format: fsunder its UUID, zip consumed.Out of scope: a zipped v3 pack carrying a
btfile is unpacked as-is but only plays on the device it was ciphered for.Closes lgnap#22
🤖 Generated with Claude Code