| Summary | unable to open zip files on Mac OS X |
| Queue | Horde Framework Packages |
| Queue Version | HEAD |
| Type | Bug |
| State | Resolved |
| Priority | 1. Low |
| Owners | |
| Requester | reitsma (at) denison (dot) edu |
| Created | 11/16/2006 (6806 days ago) |
| Due | |
| Updated | 11/16/2006 (6806 days ago) |
| Assigned | |
| Resolved | 11/16/2006 (6806 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Resolved
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ unable to open zip files on Mac OS X
Queue ⇒ Horde Framework Packages
a file that cannot be opened by the default zip handler
(BOMArchiveHelper) on Mac OS X. Zipinfo reports the contents of the
file properly. The file can be "repaired" using the following steps:
zipnote file.zip >tmp
zipnote -w file.zip <tmp
In doing this we noted that 12 bytes per file get dropped from the archive.
The mailing list reports two other zip handlers having problems with
IMP generated zip files: 7-Zip and Stuffit 11.
In Horde/Compress/zip.php I found at line 346:
/* "Data descriptor" segment (optional but necessary if archive is
not served as file). */
$fr .= pack('V', $crc);
$fr .= pack('V', $c_len);
$fr .= pack('V', $unc_len);
This amounts to 12 bytes that gets added for each file in the archive.
These are the 12 bytes that zipnote is stripping out for each file.
PKWare's appnote.txt indicates there is confusion in the use of the
data descriptor segment (should it have a signature, should it only be
used in stream processing, which bit to set if it will be used) and
promises a future appnote to resolve the confusion.
Since we did not want to touch every Macintosh on campus to set it to
use a different default zip handler we went ahead and commented out
the data descriptor segment.