mirror of
https://github.com/xCyanGrizzly/DragonsStash.git
synced 2026-09-21 05:21:43 +00:00
adminandClaude Sonnet 5
402c3177d6
A `.z01`/`.z02`/…/`.zip` set is a spanned (multi-disk) archive, not one ZIP
file cut into chunks. Both ZIP listing paths assumed the latter:
- readZipCentralDirectory fed the parts to yauzl through a concatenating
random-access reader; yauzl hard-refuses nonzero disk numbers
("multi-disk zip files are not supported"), and the EOCD's directory
pointer is volume-relative anyway.
- readScannedZipListing (the ranged, no-download path) passed a
whole-archive tailStart, making the computed directory offset wildly
negative so the parser threw RangeError on every tail size.
Both failures were swallowed upstream, so every spanned set was ingested and
uploaded with an empty file list — invisible to content and keyword search.
Add a volume-aware central-directory reader: locate the EOCD in the final
volume, resolve the directory's (volume, offset) via the disk fields, and read
just the directory bytes, spilling across volumes if it straddles a boundary.
ZIP64 spanned archives are handled through the ZIP64 EOCD locator. The
existing hand-rolled walker in central-directory.ts is reused rather than
adding a third parser.
The two shapes are told apart by filename shape, not by the detector's
multipart `pattern`, so this stays independent of how detect.ts labels them.
A set named like volumes whose EOCD reports a single disk really is a byte
split, and falls back to the concatenating reader.
Byte-split (.zip.001) and single-.zip reading are unchanged; both are now
covered by regression tests. Tests build spanned archives byte-by-byte and
cross-check against real Info-ZIP `zip -s` output (including `-fz` ZIP64)
where the CLI is available.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>