Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

From: René Scharfe <l.s.r@web.de>
Date: Apr 24, 2017, 20:06 UTC
Message-ID: <d453610f-dbd5-3f6c-d386-69a74c238b11@web.de>
In-Reply-To: <alpine.DEB.2.11.1704241912510.30460@perkele.intern.softwolves.pp.se>

Am 24.04.2017 um 20:24 schrieb Peter Krefting:

Show 19 quoted lines

> René Scharfe:
> 
>> @@ -433,6 +446,11 @@ static int write_zip_entry(struct archiver_args 
>> *args,
>>     free(deflated);
>>     free(buffer);
>>
>> +    if (offset > 0xffffffff) {
>> +        zip64_dir_extra_payload_size += 8;
>> +        zip_dir_extra_size += 2 + 2 + zip64_dir_extra_payload_size;
>> +    }
>> +
>>     strbuf_add_le(&zip_dir, 4, 0x02014b50);    /* magic */
>>     strbuf_add_le(&zip_dir, 2, creator_version);
>>     strbuf_add_le(&zip_dir, 2, 10);        /* version */
> 
> This needs to be >=. The spec says that if the value is 0xffffffff, 
> there should be a zip64 record with the actual size (even if it is 
> 0xffffffff).

Could you please cite the relevant part?

Here's how I read it: If a value doesn't fit into a 32-bit field it is set to 0xffffffff, a zip64 extra is added and a 64-bit field stores the actual value. The magic value 0xffffffff indicates that a corresponding 64-bit field is present in the zip64 extra. That means even if a value is 0xffffffff (and thus fits) we need to add it to the zip64 extra. If there is no zip64 extra then we can store 0xffffffff in the 32-bit field, though.

> Also set the version required to 45 (4.5) for any record that has zip64 
> fields.

Ah, yes indeed.

René