Re: [PATCH v2] archive-zip: Add zip64 headers when file size is too large for 32 bits

From: Johannes Sixt <j6t@kdbg.org>
Date: Apr 23, 2017, 19:49 UTC
Message-ID: <e0d1c923-a9f5-9ffc-a7e7-67f558e50796@kdbg.org>
In-Reply-To: <alpine.DEB.2.11.1704231526450.3944@perkele.intern.softwolves.pp.se>

Am 23.04.2017 um 16:51 schrieb Peter Krefting:

Show 17 quoted lines

> 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