Zip.js Files

What's Changed in v2.21.0

Bug fixes

• An entry whose declared data extent (its offset plus its compressed size) ends past the central directory is rejected by getData() with ERR_ENTRY_DATA_OUT_OF_BOUNDS at every strictness level, with or without checkOverlappingEntry. Only the end of the file used to bound it, so a stored entry stretched over the directory returned the directory bytes as its content, and only checkCrc32 could catch it
• ZipWriter#appendZip() refuses to copy an entry listed with WARNING_MISSING_ZIP64_EXTRA_FIELD, i.e. whose central directory record holds a Zip64 sentinel with no Zip64 extra field resolving it: the method throws ERR_EXTRAFIELD_ZIP64_NOT_FOUND before writing anything, unless the filter option leaves the entry out. Such an entry used to be copied with zero sizes in the rebuilt central directory, or only its local file header through a filter, so the output entry was silently unreadable
• An entry whose central directory record lacks its Zip64 extra field is now parsed to the end of the record before the defect is reported, so its compression method, dates and other fields are listed with it. An entry whose local file header offset is the unresolved sentinel no longer makes the archive report "prepended data" from the offsets of the other entries
• The options passed to ZipReader#getEntries() and getEntriesGenerator() now reach the entries: entry.getData() reads them after its own options and before those of the ZipReader constructor, so a strictness, checkLocalDirectory, password or filenameEncoding given to getEntries() applies to the data as the type declarations described
• A central directory offset stored past the end of the file, e.g. in a damaged or truncated end of central directory record, is reconciled with the directory found before the record instead of failing with ERR_BAD_FORMAT, with the WARNING_MISMATCHED_CENTRAL_DIRECTORY_OFFSET reason deposited and the "strict" level rejecting the archive as before. The same reconciliation now covers a Zip64 end of central directory record stored at the wrong offset: the record is looked for right before its locator, then by its signature within the range the locator allows
• Before shifting the entries of an archive whose stored central directory offset does not match the directory found, the reader checks that the local file header of the first entry is found at the shifted position and not at the stored one; an archive whose stored offset is short of the directory while its entries sit at the shifted positions is diagnosed as WARNING_PREPENDED_DATA. The shift used to be decided on the direction of the mismatch alone, and a damaged offset could move the entries away from their local file headers
• An empty archive, i.e. one with no entry, behind prepended data is diagnosed with WARNING_PREPENDED_DATA and its prefix is extracted with extractPrependedData as for a non-empty one; it used to be read without a warning
• The CRC-32 checksum and the sizes of the data descriptor are compared with the central directory record when the descriptor is read, i.e. when checkOverlappingEntry is set, and a mismatch is reported as WARNING_MISMATCHED_LOCAL_FILE_HEADER_CRC32_OR_SIZES, an error or a warning depending on checkLocalDirectory. A local file header whose CRC-32 checksum and sizes are all zero without the data descriptor flag is tolerated, because some streaming writers leave these fields blank
• Reading an archive whose end of central directory record points into entry data holding the archive extra data signature no longer takes that data for an encrypted central directory: the record is only looked for at the start of the central directory, where the specification places it
• EntryMetaData#lastAccessDate and creationDate keep the values of the central directory record when it holds them; the values of the NTFS extra field of the local file header used to overwrite them once the data of the entry was read. When the central directory record holds none, e.g. with the extended timestamp field, whose central form stores the modification time only, the local file header stays their source

appendZip() with the filter option

• Each kept entry is copied from its local file header up to the exact end of its data or, when it has one, of its data descriptor, whose layout is read back from the zip file. The bytes outside the kept entries are dropped: a self-extracting stub, the data of entries removed earlier and the padding between entries, so a zip file aligned with the usdz option is not aligned any more once filtered. The copy used to stop at the next entry or at the central directory, so the data of a removed entry that followed a kept one was carried into the output
• Before anything is written, each kept entry is checked to start with a local file header and to end before the next entry or the central directory; otherwise the method throws ERR_LOCAL_FILE_HEADER_NOT_FOUND or ERR_OVERLAPPING_ENTRY and leaves the current zip unchanged. The same checks apply when the output is a split zip file, whose entries are copied one by one as well
• The general purpose bit flag of a copied entry is written as-is in the rebuilt central directory, including the bits zip.js never sets itself. A filtered copy into a split zip file writer now starts the first disk with the split zip file signature whatever the source starts with
• A copy that fails after some bytes were written marks the ZipWriter with hasCorruptedEntries and the error with corruptedEntry, as add() does; a failure before the first byte leaves the writer clean. Every filter call completes before any data is copied

Documentation

• appendZip() states that the comment and the digital signature of the zip file are not copied, since its central directory is rebuilt, and that a source copied as a whole into a split zip file writer carries its self-extracting stub after the split zip file signature of the first disk, where no system runs it; ERR_LOCAL_FILE_HEADER_NOT_FOUND, ERR_OVERLAPPING_ENTRY, ERR_EXTRAFIELD_ZIP64_NOT_FOUND and ERR_ENTRY_DATA_OUT_OF_BOUNDS say when the method and getData() throw them
• WARNING_MISMATCHED_CENTRAL_DIRECTORY_OFFSET covers both directions of the mismatch and names the local file header check that decides the shift; WARNING_MULTIPLE_END_OF_CENTRAL_DIRECTORY states that it is never deposited as a warning, since "balanced" rejects it like "strict" and "tolerant" reads the last record and reports the stale one as WARNING_TRAILING_CENTRAL_DIRECTORY_DATA; the reasons of ERR_AMBIGUOUS_ARCHIVE list "mismatched central directory offset"
• checkLocalDirectory describes the data descriptor comparison and the blank local file header tolerance; lastAccessDate and creationDate say which record they are read from

Dependencies

• The transitive development dependency brace-expansion is updated in the lock file of the benchmarks; no runtime dependency changed, zip.js has none

Full Changelog: https://github.com/gildas-lormeau/zip.js/compare/v2.20.0...v2.21.0

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