Am 23.04.2017 um 16:51 schrieb Peter Krefting:

Johannes Sixt:

quoted

quoted

@@ -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