gman.zipengine bug

When reading a password-protected zip file, only the first file name is read:

Import gman.zipengine

zrObject:ZipReader=New ZipReader
zrObject.OpenZip("textures.pak")
For Local i:Int=0 To zrObject.getFileCount()-1
	filename$=zrObject.getFileInfo(i).zipFileName
	Print filename
Next

The filenames themselves are not password-protected in a zip file, and should be accessible.

Bump?

Have you tried Koriolis's zipstream module by any chance?

That doesn't retrieve the file names in a zip file.

greetings :) i am unable to replicate the issue. here is a sample download:

http://www.gprogs.com/pub.zipengine/test_multi_file_pass.zip

the sample ZIP was created using IZArc with the PKZip password option and the password is "test".

the zipengine sample also does multi-file in its "Password Example 2" section. it can be downloaded here:

http://www.gprogs.com/pub.zipengine/zipsample.zip

how was the PAK file created? if possible, please email me a sample with password.

thank you.

Here's a sample with bmx source: http://forum.leadwerks.com/viewtopic.php?p=22181#p22181
The pak file was created with WinRAR, using ZIP format and best compression mode. The password is hello.

thank you for the sample. i believe its something to do with WinRAR and how it does passwords. i have now tried IZArc (using PKZip 2.0 password option), PKZip (using traditional password encryption), and a password zip created with the zipengine. all work with password. i could not find any password options in WinRAR. my guess is that its using a better encryption method of password causing it to not be compatible. unfortunately, this falls above my knowledge of ZIP. i would recommend trying IZArc or PKZip to create the PAK file.

That explanation does not seem likely to me.

greetings :) in any case, there is something different with WinRAR. as stated, i have tested both IZArc and PKZip with the settings mentioned and both work fine. WinRAR without a password also works fine. once a password is added in WinRAR it fails at that point, with zipengine unable to properly read the file header. without knowing what structure its using for the zip header i wont be able to read it in.

I quit using WinRAR because the zip files I created with it were strangely losing their CRC32 property when uploaded to my website. It seems gman is right. There is something different with the last versions of WinRAR. I can't figure out what it is though.

im onto something. seems WinRAR is including the data descriptor section of the ZIP format header, where the other compression programs are not. WinRARs header is different, but i do feel there is a potential bug in ZipEngine in reading this in. the first files compressed size is reporting off what it should be. hmmm...

there is a new release of the ZipEngine that should now be compatible with WinRAR created ZIP files with a password. i switched the mod to read from the central file directory instead of the local. also, while i was in there i added a stream wrapper for OpenStream(). you can now open a file within a zip file using the following syntax in OpenStream().

so an example would look something like:

Local logo_file:TStream = OpenStream("zipe::game_files.zip::logo.png::gman")

password is optional so leave it off if there is none. the wrapper is fairly untested so please report any bugs on my forum. you can download the new mod here.

Thanks, will try.

Seems to work, thanks!

I am using this together with koriolis.zipstream. Did you call the function protocol "zipe" to avoid conflicting with that?

fantastic news thank you!

interesting. didnt even know about that one. since the wrapper is driven by zipengine i used the protocol "zipe". im curious to see the koriolis implementation now. have to do some searching to find that one.

i havent seen the code but kudos to koriolis. looks like from the specs the stream is much more advanced than this one! feel bad for duplicating effort now :\ aw well. learning experience :) for anyone curious see here.

Hey, the more choices the better. :-)

Agreed!

The new module takes approximately 4000% the time to retrieve the file names as the previous version. This has led to a significant increase in the startup time of all Leadwerks Engine apps:
http://forum.leadwerks.com/viewtopic.php?f=15&t=2709

greetings :) my apologies on that. please download v2.10 and give it a whirl. i updated the central header scan routine to be more efficient.

Thanks, the startup time is back down to 77 msecs.