Zip files created with store method can not be extracted on android devices

[mlegenhausen]

The method how you create the file with node-archiver is irrelevant only { store: true } is relevant. Transfering the data to an android device and extracting the file with the ZipInputStream creates the following error:

java.util.zip.ZipException: unknown format (EXTSIG=6d783f3c)
E/Zip     (28060):  at java.util.zip.ZipInputStream.readAndVerifyDataDescriptor(ZipInputStream.java:196)
E/Zip     (28060):  at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:167)
E/Zip     (28060):  at org.apache.cordova.Zip.unzipSync(Zip.java:144)
E/Zip     (28060):  at org.apache.cordova.Zip.access$000(Zip.java:23)
E/Zip     (28060):  at org.apache.cordova.Zip$1.run(Zip.java:39)
E/Zip     (28060):  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
E/Zip     (28060):  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
E/Zip     (28060):  at java.lang.Thread.run(Thread.java:841)

The EXTSIG value depends on the file content.

Using node-archiver without the store flag creates a valid zip file and can be extracted on android devices.

Generating files from the command line via zip -0 file.zip file.txt can be extracted on the android devices. Tested on Android 4.4 and 5.0 in simulator and real devices.

I can uncompress the generated file from node-archiver on Mac OS 10.10, Linux Machines and even on iOS devices. Only Android seems to be more strict.

Tested with node-archiver HEAD version.

[ctalkington]

i know some parsers don't like data descriptors in different modes. then theres mac archive utility which is also picky.

i dont recall what the sig goes too as its represented a bit different than the constants defined.

thanks for the report though and ill see what can be done.

[ctalkington]

EXTSIG here is definitely referring to the data descriptor. looking at it, im wondering if its unhappy with my efforts to reduce size by only using data descriptors when needed. though spec allows this..

[mlegenhausen]

Is it possible to enable these data discriptors permanently? So I can see if this solves the bug?

[ctalkington]

currently its based on need, theres no real toggle

[mlegenhausen]

Could you give me a code hint? I don't want to switch to a command line tool for zipping and this bug is really urgent for us.

[ctalkington]

if you could create the bare minimum needed to reproduce this in a repo that i can clone and try out. i did some very basic tests on my moto x 2nd gen (4.4) that seemed to work though that was with es explorer which im not sure what underlying lib it uses.

[mlegenhausen]

I can provide you my test project that I created with the script that uses node-archiver to produce the zip file. I try to make it today.

[ctalkington]

@mlegenhausen let me know when your able to provide something to test on.

[mlegenhausen]

I am sorry I am little bit busy currently. I needed to change to the native zip function from Ubuntu cause this was a blocking problem for me. I will try to provide an example as soon as possible.

[ctalkington]

no problem, i know how it goes. do let me know when you come up with a test repo.

[mlegenhausen]

So I had the problem again even with the native zip command from ubuntu. After some research and diffing of files it seems that the problems lies in encoding problems of file paths (or even more in the binary part). I solved the problem by switching to p7zip which created valid zip files for android on the first try. I think you can reproduce the problems by using unzip and then zip again. The resulting files should be differ. Which makes it really hard to track it down cause you normally think the resulting zip should be the same again.

[ctalkington]

really could use some insight from someone who works with android builds as the encoding used definitely works with Windows/Mac/Ubuntu from what ive seen. Android seems to following a different spec or such.