@zip.js/zip.js 2.18.1 on Node.js NPM

What's Changed in v2.18.1

LocalDataDescriptor has a zip64 property, true when the sizes of the data descriptor read with checkOverlappingEntry are stored as 8-byte values

With checkOverlappingEntry set, an entry placed past 4 GB whose data descriptor stores 4-byte sizes now reads; getData() used to fail with ERR_UNSUPPORTED_UINT64. The width of the sizes was taken from the presence of a Zip64 extra field in either record, but neither record tells it reliably: the local file header is written before a streaming writer knows the sizes, and the Zip64 extra field of the central directory record, written last, describes that record, not the descriptor. Go's archive/zip, for instance, gives a small entry placed past 4 GB a Zip64 extra field in its central directory record for the offset alone and a 4-byte descriptor, while its large streamed entries get an 8-byte descriptor with no local Zip64 extra field, which is why the central directory record was consulted; the descriptor of the small entry was therefore read as 8 bytes wide, across the next record. The descriptor is now read with the layout, among the two widths with and without the signature, whose CRC-32, when the entry stores one, and sizes agree with the central directory; when none does, it is read at the width the Zip64 extra field of either record announces, without the signature, as before. Reading without checkOverlappingEntry never depended on the descriptor and is unchanged

A new test builds the archives by hand, behind a reader that fakes a 4 GB prefix so the offsets are real, and reads a 4-byte descriptor below and past 4 GB, signed and unsigned, and an 8-byte descriptor whose Zip64 extra field is in the central directory only or in neither record, each in both read orders, and a descriptor agreeing with no layout

Full Changelog: v2.18.0...v2.18.1

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com