ZIP Plugin Doesn't Unpack Entire Archive

Other
#1

Hi

Is there some specific zip compression that is recommended? I am having huge problems on zip plugin and the success of my app largely depends on solving these issues.

Simply put, zip plugin will sometimes unpack entire archive, sometimes just a part of it - and I am talking about the same zip file that sometimes will extract correctly, and sometimes not. I am having large archives (~400Mb) with files structured in subfolders. 

I didn’t find any correlation between the code and the behaviour of the zip plugin. I run the app in Simulator, and the zip will extract correctly. Then I run it again, without changing either code or zip file, and it will only extract a few files (notably the first subfolder only, and one file in the subfolder).

I am running Corona 2013.1137, and zip files I produced both via OSX and using BetterZip, and the problem persist (additionally, if I compress using OSX finder, I’ll get an ugly resource fork __MACOSX folder too, but this doesn’t affect the results of the zip plugin).

Any ideas?
Thanks

#2

Just to confirm,the same problem persists with latest nightly build, too.

Looks like zip plugin just simply stops working and extracts just a couple of first files and folders it comes accross.

#3

Ok, I think I figured this out. Seems that zip plugin is not thread safe, and other Lua code can affect the workings of the plugin.

So here’s in the nutshell how my program was structured ( the part around the zip extraction ):

  • Extract zip file.

  • Continue app logic once the extraction is done ( via zip listener ).

  • Do something else, including using lfs to check files in another folder (let’s cal it “intro”).

Now the weird thing is that zip actually was extracting entire archive all the time, but it was putting the extracted files into wrong folder, and it was the same folder I  later used lfs commands to check files and stuff.

Which is hugely weird behaviour: somehow my actions using lfs *AFTER* the zip was supposed to be finished, affected the functionality of zip plugin and “redirected” its target directory to another one.

This probably means that zip listener is called too soon, before the files are finished writing, otherwise I don’t know how this could happen.

So in order to work around the issue I had to reorder the execution of some things, making sure that I use timer of at least half a second BEFORE and AFTER calling zip plugin to make sure no code will interfere.
 

#4

Just to confirm,the same problem persists with latest nightly build, too.

Looks like zip plugin just simply stops working and extracts just a couple of first files and folders it comes accross.

#5

Ok, I think I figured this out. Seems that zip plugin is not thread safe, and other Lua code can affect the workings of the plugin.

So here’s in the nutshell how my program was structured ( the part around the zip extraction ):

  • Extract zip file.

  • Continue app logic once the extraction is done ( via zip listener ).

  • Do something else, including using lfs to check files in another folder (let’s cal it “intro”).

Now the weird thing is that zip actually was extracting entire archive all the time, but it was putting the extracted files into wrong folder, and it was the same folder I  later used lfs commands to check files and stuff.

Which is hugely weird behaviour: somehow my actions using lfs *AFTER* the zip was supposed to be finished, affected the functionality of zip plugin and “redirected” its target directory to another one.

This probably means that zip listener is called too soon, before the files are finished writing, otherwise I don’t know how this could happen.

So in order to work around the issue I had to reorder the execution of some things, making sure that I use timer of at least half a second BEFORE and AFTER calling zip plugin to make sure no code will interfere.