[Zlib-devel] TR: Minizip

[Gilles Vollant]

Hello,

I received a patch proposal for minizip at

 

http://gvollant.free.fr/minizip_patch_derek_proposal.zip

 

this look good for me, but before asking Mark to include it, I’ll be happy
if you can test it

 

regards

Gilles Vollant

 

De : Gilles Vollant [mailto:info at winimage.com] 
Envoyé : jeudi 9 février 2012 14:24
À : Mark Adler <madler at madler.net> (madler at madler.net)
Objet : TR: Minizip

 

I’ll take a look, I cc to you for info

 

De : Derek Edson [mailto:Derek.Edson at sss.co.nz] 
Envoyé : jeudi 9 février 2012 03:48
À : info at winimage.com
Objet : Minizip

 

I just downloaded and built minizip based on zlib-1.2.6 

I have a found a bug with unzip.c when extra attributes are present.  The
existing code attempts to move back to the beginning of the extra attributes
by using a negative offset to the current position, however the offset
parameter is unsigned.   

I was using a 32-bit filefunc, so ZSEEK64 fails on (offsetTruncated !=
offset), otherwise it would move to the end of file. 


    if ((err==UNZ_OK) && (file_info.size_file_extra != 0)) 
    { 
                uLong acc = 0; 

        // since lSeek now points to after the extra field we need to move
back 
        lSeek -= file_info.size_file_extra; 

        if (lSeek!=0) 
                { 
                        /* DNE: cannot move backwards as ZSEEK64 is unsigned

                                        so we need to get current positin
and add lSeek ourselves 

                        if (ZSEEK64(s->z_filefunc,
s->filestream,lSeek,ZLIB_FILEFUNC_SEEK_CUR)==0) 
                                lSeek=0; 
                        else 
                                err=UNZ_ERRNO; 
                        */ 
                        ZPOS64_T cur = ZTELL64(s->z_filefunc,s->filestream);

                        cur += lSeek; 
                        if (ZSEEK64(s->z_filefunc,
s->filestream,cur,ZLIB_FILEFUNC_SEEK_SET)==0) 
                                lSeek=0; 
                        else 
                                err=UNZ_ERRNO; 
                } 


I have also modified the code to improve performance (unnecessary I/O).   

Both unzip.c and zip.c first search for the zip64 end of central directory
locator, and only if this fails will it search for the normal zip end of
central directory record. Given that most zip files being processed are more
likely to be standard, rather than zip64, the code will unnecessarily search
the last 64KB looking for a non-existant header.   

The modified code now searches for the end of central directory record in
all cases, which will more likely be found within the first 1KB.   

Only if the number of files exceeds 0xffff or the offset exceeds 0xffffffff
does the modified code get the zip64 end of record locator.  Since this
record is fixed length and is located immediately prior to the end of
central directory record, it can be located without any more searching.   

This also has an added advantage that the global comment size is read from
the end of central directory record for both normal and zip64 files. 

The modified searching technique is now consistent with the way in which
zip.c creates a zip64 file, that is it only writes the zip64 end of central
directory record when the number of files or offset exceed the field sizes. 

Thank you for producing this code, and attached is my modified version. 



Derek   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://madler.net/pipermail/zlib-devel_madler.net/attachments/20120212/ca66a6a3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip.c
Type: application/octet-stream
Size: 64819 bytes
Desc: not available
URL: <http://madler.net/pipermail/zlib-devel_madler.net/attachments/20120212/ca66a6a3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unzip.c
Type: application/octet-stream
Size: 68357 bytes
Desc: not available
URL: <http://madler.net/pipermail/zlib-devel_madler.net/attachments/20120212/ca66a6a3/attachment-0001.obj>