Am 24.04.2017 um 23:02 schrieb Johannes Sixt:
Am 24.04.2017 um 22:06 schrieb René Scharfe:
Am 24.04.2017 um 20:24 schrieb Peter Krefting:
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.
The reader I wrote recently interprets 0xffffffff as special if the
version is 45. Then, if there is no zip64 extra record, it is a broken
ZIP archive. You are saying that my reader is wrong in this special case...
The "version needed to extract" field is not particularly well-suited
for feature detection. If you e.g. compress with LZMA then it should be
set to 63 even for small files that need no zip64 extra field. So it
seems to rather be meant to allow readers to spot headers they can't
interpret because they were written against an earlier version of the
spec.
InfoZIP's zip writes 10 into the version field, no matter if the entry
has a zip64 extra field or not, as I wrote in my other reply. That
seems to collide with the spec, but I'd expect readers to be able to
handle its output.
René