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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> [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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Logged In: YES
user_id=65083
Some ZIP packers do not follow ZIP format specification.
So you can fix such archives with pkzipfix
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
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
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
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.
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.
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.