Menu

#291 unzip.exe unpacks this zip file but 7-zip not

open
nobody
None
5
2012-12-07
2004-11-04
No

Hi,

I attched a small zip file to this message. unzip.exe
on DOS unpack very well, but 7-zip could not.

CC Vural

Discussion

  • Cavit Cahit VURAL

     
  • Hans Fr. Nordhaug

    Logged In: YES
    user_id=21914

    I have another zip-file that 7-zip doesn't handle, but unzip
    (UnZip 5.12 of 28 August 1994, by Info-ZIP) unpacks with
    no problems. Get it from
    http://www.mi.uib.no/~hansfn/temp/pivot.zip

    Tested with 7-zip 3.13 (on windows 2000 pro) and
    7-Zip 4.10 beta (on windows XP home).

    This is a very serious problem making 7-zip almost useless
    since we don't know if we can trust it....

    Except for this - thanks for your great work.

     
  • Igor Pavlov

    Igor Pavlov - 2004-11-10

    Logged In: YES
    user_id=65083

    Some ZIP packers do not follow ZIP format specification.
    So you can fix such archives with pkzipfix

     
  • Hans Fr. Nordhaug

    Logged In: YES
    user_id=21914

    Thx for a quick reply, ipavlov. If my example - pivot.zip -
    doesn't
    follow the ZIP format specification, I would be very glad if
    you
    could point to any specific issues with the file. The file
    is created
    by a PHP script (part of Pivot) that claims to follow the
    specification...

    Thx, Hans

     
  • Hans Fr. Nordhaug

    Logged In: YES
    user_id=21914

    Actually Pivot is using this code:
    http://www.zend.com/codex.php?id=696&single=1
    Can you spot were the code don't
    follow the ZIP format specs?

    I realize that you might not have time for
    this - I just thought it might be trivial for
    you.

    Thx, Hans

     
  • Hans Fr. Nordhaug

    Logged In: YES
    user_id=21914

    I found the bug in the PHP script myself. Using zipinfo I got warned - "There are an extra 12 bytes preceding this file". Looking closely at the code at http://www.zend.com/codex.php?id=696&single=1 I noticed that the general bit wasn't set so then "data descriptor" segment shouldn't have been included. Remove these 12 bytes 7-zip is happy. (This is for my example pivot.zip.)

    Please consider making 7-zip more robust. Sorry for taking your time.

    Hans

     
  • Nobody/Anonymous

    Logged In: NO

    > Some ZIP packers do not follow ZIP format specification.
    > So you can fix such archives with pkzipfix

    Isn't that defeats the purpose of switching away from PKZIP,
    if fixing zip files requires proprietary tool? As later
    post revealed, it was caused by extra bytes inserted in
    front of zip file by the script. 7-Zip can trigger this
    'error' alone by trying to process multivolume zip or zip
    from self-extracting zip archive. Technically, you only
    need local file header to extract zip files. But for added
    safety, 7-Zip should look up central directory record and
    local file header signatures to determine the real size of
    embedded zip contents within a file*. But if central
    directory record isn't available, 7-zip should attempt to
    recover data using local headers alone.

    Compliant ZIP tools should not rely on hardcoded values to
    determine the locations of embedded zip contents. According
    to .ZIP File Format Specification [1], spanned/split
    archives created with this special signature are compatible
    with all versions of PKZIP, that implies PKZIP 0.x and 1.x
    (which had not been designed to handle split archives) will
    scan for signatures to look for embedded contents rather
    than relying on fixed 'padding size' to locate zip contents.
    Therefore we can conclude that the signature seeking is the
    recommended method of identifying .zip structures.

    * If it is a proper zip file, the embedded size equals to
    actual zip file size for non-volume archive. For
    multivolume zip, first volume can contain a 0x08074b50 or
    0x30304b50 signature[1], making total file size for all
    volumes 4 bytes bigger than the non-splitting zip archive.

    [1] APPNOTE.TXT - .ZIP File Format Specification 6.2.0
    (http://www.pkware.com/company/standards/appnote/), section
    VI. chapter K., note 5.

     
  • Nobody/Anonymous

    Logged In: NO

    > [1] APPNOTE.TXT - .ZIP File Format Specification 6.2.0
    (http://www.pkware.com/company/standards/appnote/), section
    VI. chapter K., note 5.

    Actually, it should in section IV, not VI. The document
    shows section 'General Format of a .ZIP file' as section
    'VI', but this instance of the 'VI' is a misprint.

     
  • Nobody/Anonymous

    Logged In: NO

    Actually, section 'General Format of a .ZIP file' should be
    in section IV, but the number 'VI' is a misprint in the
    document itself. Nevertheless, the previous post refers to
    section 'General Format of a .ZIP file', for those who are
    confused.

     

Log in to post a comment.