[fixed]Can't read certain zip files

[hiker]

Hi,

in supertuxkart we have started to use the zip file reader from irrlicht. Unfortunately it can't read certain zip files (so far noticed with zip files created on Macs). I think that the problem is actually a design problem of the zip file reader, so here a somewhat thorough description of the bug based on http://en.wikipedia.org/wiki/ZIP_(file_format) (note that the (file_format) belongs to the link, I couldn't convince the URL bbcode to display that link correctly).

Debugging showed that problem are zip files that do not contain the length of the compressed (and uncompressed) chunk in the headers at the beginning of a file. Looking at wikipedia article linked above this appears to be valid:

If bit 3 of the general-purpose flags field is set, then the CRC-32 and file sizes are not known when the header is written, and they are appended (in a 12-byte structure) immediately after the compressed data. The fields in the local header are filled with zero.

CZipReader actually tests this condition:

Code: Select all

        // if bit 3 was set, read DataDescriptor, following after the compressed data
        if (entry.header.GeneralBitFlag & ZIP_INFO_IN_DATA_DESCRIPTOR)
        {
                // read data descriptor
                File->read(&entry.header.DataDescriptor, sizeof(entry.header.DataDescriptor));

but it just reads the wrong section - the beginning of the compressed data. For this code to be correct the reader would first have to seek to the end of the compressed data - which it can't since it doesn't know the size

It looks like it is necessary to actually start reading the central directory at the end of a zip file, in order to find the proper locations of all chunks.

As a test case you can use: http://download.tuxfamily.org/stkaddons ... /Monty.zip

If you try reading this file with irrlicht, the reader only finds two files (and accessing the 2nd file actually causes memory corruption) - the first one a directory 'monty/', the second one 'monty/.DS_Store' is the one triggering the problem. I assume you have a simple program in your test suite that tests zip files, so you should be able to just add this file. Just test for number of files in the zip files.

Zip readers on linux and windows (and I am sure Macs, since it's a Mac file) can read this file without any problems.

Cheers,
Joerg

[hybrid]

Interesting problem. We do indeed not support all zip file types out there. But I'll check the current loader if we can do something about this here.

[hybrid]

I can't help it, file formats simply challenge me. It's fixed in SVN/trunk. Please note that loading such files will take longer than those with the information kept locally. The algorithm needs to seek a lot in the file.