Skip to content

v1.2.0

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 06 Nov 10:22
· 1 commit to main since this release
v1.2.0
51053d1

Additive over 1.1.1: no public API was removed or changed, and compressed bytes are unchanged for every codec and level. Zip archives change only in the local headers of zip64 entries whose sizes follow in a data descriptor, and in raw-copied entries written without a "version needed to extract" (see Fixed).

Added

  • Zip raw entry copy, for callers that carry untouched parts from one archive to another without decompressing and recompressing them: ZipReader.OpenRawEntryStream(ZipEntry) returns an entry's stored bytes (compressed data plus any ZipCrypto header or WinZip AES salt, verifier and authentication code) with no decoding, decryption or CRC check, in seekable, LazyDirectory and forward-only modes (forward-only needs the sizes in the local header and otherwise raises ArchiveUnsupportedException); ZipWriter.WriteRawEntry / WriteRawEntryAsync with ZipRawEntry (and ZipRawEntry.FromEntry) write an entry from a header and such a stream, rewriting zip64 fields, dropping stale alignment padding and checking that the stream holds exactly the declared compressed size. ZipEntry gained RawComment, DosTime, DosDate and UncompressedSize. See docs/zip.md.
  • The zip-raw-copy fuzz target.

Fixed

  • A raw-copied zip entry whose ZipRawEntry.VersionNeeded was not set got "version needed to extract" 0, which some readers treat as damage. VersionNeeded is now ushort?: null (the default) picks the value from the method as the ordinary writer does (10 stored, 20 deflate, at least 20 for directories), and an explicit value is still written as given.
  • Zip64 local headers of entries whose sizes follow in a data descriptor now carry zero sizes instead of 0xFFFFFFFF (APPNOTE 4.4.4); Excel refuses the latter. The zip64 extra field stays, with zeroed sizes, and the descriptor still holds 8-byte sizes.
  • A disposed ZipReader no longer keeps its central directory alive, so an Archive.EnumerateEntries() sequence held after the loop does not pin it.
  • Documentation: Archive.EnumerateEntries() keeps memory flat for a zip only with LazyDirectory (the 1.1.1 note read as if it did on its own).

Changed

  • The SDK pin in global.json is 10.0.403 (a runtime patch level that AOT restore needs).
Assets 6
Loading