I have a PDX build which works as expected, in simulator and sideloaded via USB and play.date/account/sideload. I used the MacOS "Compress" right click option to create a ZIP of the same PDX and while the website accepts it, it fails on device when you attempt to install.
I have attached two zip archives, one created with the MacOS zip compressor (11.6.5) and one created with the command line zip (zip -r gimmefriction_clizip.pdx.zip net.notpeter.gimmefriction_1.0.0-build13_2022-05-10_232421.pdx).
Thank you @SHiLLySiT. I believe there is an issue with how itch processes the upload.
gimme-friction-baby-1.1.2.pdx.zip -- My original zip upload. (OK)
gimme-friction-baby-1.1.2.pdx -- Extracted from my zip. (OK)
gimme-friction-baby-playdate.zip -- Zip file downloaded from Itch (NOT OK)
gimme-friction-baby-1.1.2.pdx -- Extracted from the itch zip. (OK)
I have NO IDEA what is causing the issue decompressing on-device.
The pdx directory extracted from each is identical (as compared by diff -bur
As expected the files contained in the two zip files are identical, but it appears the order they appear in the archive differs. Specifically the itch zip defines all the directories first:
I can totally imagine that whatever software the playdate hardware is using to extract the zip archive is making an assumption about zip archive structure that is not true of this zip file.
It appears my original zip (created by the command line zip (Info-Zip 3.0 on MacOS) creates directories and then their contents (a sane structure) while the Itch tooling creates all directories first (in no particular order) and then files in those directories.
zip -sf gimme-friction-baby-1.1.2.pdx.zip output orig112.txt.zip (509 Bytes)
zip -sf gimme-friction-baby-playdate.zip output itch112.txt.zip (509 Bytes)
I will reach out to Itch support, but in the meantime the workaround seems to be to extract pdx diretcories before sideloading at play.date/account/sideload -- cause if you sideload the itch zip you're gonna have a bad time.
My guess is that it may be because I use nested subdirectories (e.g. /images/balls/ and /images/loader ) while many folks may not. It might also happen non-deterministically (e.g. reading directories from an unordered hash table) but I'm not sure. Looking at the PKZIP specification I don't believe the Itch zip to be technically invalid (my understanding is that file/directory entries may occur in any order) but in my investigations the other zip implementations follow the somewhat sane pattern of creating parent directories before their child directories and files.
I don't know which zip library Playdate is using on device (or god forbid they created their own). But it's not surprising that there are some gremlins in a compression format created in 1989 (33 years ago) and shoehorned onto a modern device.
And this zip correctly installs! Yay! So the solution is just don't use subdirs! Or wait until Panic fixes their zip library or Itch fixes their zip writer. Thanks everyone for your help especially @SHiLLySiT as your comment led me down the correct thought process, so many thanks!
Thank you for all of the investigation into this issue!
As you figured out, the bug is triggered on the device when the first entry of the zip file list is not the root directory, so in the example problem game posted, it's gimme-friction-baby-1.1.2.pdx/images/loader/ rather than gimme-friction-baby-1.1.2.pdx (which is instead the 4th entry). I am not sure what the circumstances are that cause this to happen when creating an archive or how we haven't managed to run into the problem earlier, but we have a fix in the works that will be included in the next firmware update.