Am 23.04.2017 um 08:42 schrieb Peter Krefting:
René Scharfe:
The offset is only needed in the ZIP64 extra record for the central
header (in zip_dir) -- the local header has no offset field.
Good point.
The zip64 local header does have an offset field, though. I thought that
was the zip_offse
René Scharfe:
The offset is declared as unsigned int, so will wrap on most platforms
before reaching the clamp check. At least InfoZIP's unzip can handle
that, but it's untidy.
Right, that needs to be changed into unsigned long and clamped, just
like the original and compressed file sizes al
Am 22.04.2017 um 23:52 schrieb Johannes Sixt:
Am 22.04.2017 um 21:22 schrieb Peter Krefting:
@@ -279,6 +299,7 @@ static int write_zip_entry(struct archiver_args
*args,
int is_binary = -1;
const char *path_without_prefix = path + args->baselen;
unsigned int creator_version = 0;
+
Am 22.04.2017 um 21:22 schrieb Peter Krefting:
@@ -279,6 +299,7 @@ static int write_zip_entry(struct archiver_args *args,
int is_binary = -1;
const char *path_without_prefix = path + args->baselen;
unsigned int creator_version = 0;
+int clamped = 0;
crc = crc32(0, NULL, 0
If the size of the files in the archive cannot be expressed in 32 bits, or
the offset in the zip file itself, add zip64 local headers with the actual
size. If we do find such entries, we also set a flag to force the creation
of a zip64 end of central directory record.
Signed-off-by: Peter Kreftin
5 matches
Mail list logo
