Am 23.04.2017 um 16:51 schrieb Peter Krefting:
Johannes Sixt:
@@ -376,7 +397,7 @@ static int write_zip_entry(struct archiver_args
*args,
copy_le16(dirent.comment_length, 0);
copy_le16(dirent.disk, 0);
copy_le32(dirent.attr2, attr2);
- copy_le32(dirent.offset, zip_offset);
+ copy_le32(dirent.offset, clamp_max(zip_offset, 0xFFFFFFFFU,
&clamped));
I don't see any provisions to write the zip64 extra header in the
central directory when this offset is clamped. This means that ZIP
archives whose size exceed 4GB are still unsupported.
The clamped flag will trigger the inclusion of the zip64 central
directory, which contains the 64-bit offset. Should the central
directory entry also have the zip64 extra field?
There is no "zip64 central directory". There is a "zip64 end of central
directory record"; it tells where to find the "central directory" in
case that the ZIP archive exceeds 4GB. The central directory has the
same format in a non-zip64 and a zip64 archive. But when size,
compressed size, and offset overflow 4GB, it uses the same zip64 extra
record like the local header records, except that it has to record an
offset in addition to the uncompressed and compressed sizes.
The uncompressed and compressed sizes of entries are mentioned in both
the central directory and the individual local headers. I think that the
central directory's values are authorative; my reasoning is that it is
possible that the local header can have a bit set that tells that the
local header's values size values are garbage.
In summary, yes, when the central directory is constructed, it must use
the zip64 extra record to note the values of uncompressed size,
compressed size, and the offset to the local header when they overflow 4GB.
-- Hannes