gman.zipengine bug

BlitzMax Forums/BlitzMax Programming/gman.zipengine bug

JoshK

(Posted 2008) [#1]

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.

JoshK

(Posted 2009) [#2]

Bump?

xlsior

(Posted 2009) [#3]

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

JoshK

(Posted 2009) [#4]

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

gman	(Posted 2009) [#5]

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.

Canardian

(Posted 2009) [#6]

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.

gman	(Posted 2009) [#7]

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.

JoshK

(Posted 2009) [#8]

That explanation does not seem likely to me.

gman	(Posted 2009) [#9]

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.

byo	(Posted 2009) [#10]

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.

gman	(Posted 2009) [#11]

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...

gman	(Posted 2009) [#12]

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().

zipe::zipfilename::file_in_zip::password

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.

JoshK

(Posted 2009) [#13]

Thanks, will try.

JoshK

(Posted 2009) [#14]

Seems to work, thanks!

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

gman	(Posted 2009) [#15]

fantastic news thank you!

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

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.

gman	(Posted 2009) [#16]

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.

xlsior

(Posted 2009) [#17]

feel bad for duplicating effort now :\

Hey, the more choices the better. :-)

Brucey

(Posted 2009) [#18]

Hey, the more choices the better.

Agreed!

JoshK

(Posted 2009) [#19]

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

gman	(Posted 2009) [#20]

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.

JoshK

(Posted 2009) [#21]

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