(no title)
gildas | 4 months ago
[1] https://gildas-lormeau.github.io/zip.js/api/classes/HttpRang...
[2] https://github.com/gildas-lormeau/zip.js/blob/master/tests/a...
gildas | 4 months ago
[1] https://gildas-lormeau.github.io/zip.js/api/classes/HttpRang...
[2] https://github.com/gildas-lormeau/zip.js/blob/master/tests/a...
toomuchtodo|4 months ago
gildas|4 months ago
duskwuff|4 months ago
1) The format has limited and archaic support for file metadata - e.g. file modification times are stored as a MS-DOS timestamp with a 2-second (!) resolution, and there's no standard system for representing other metadata.
2) The single-level central directory can be awkward to work with for archives containing a very large number of members.
3) Support for 64-bit file sizes exists but is a messy hack.
4) Compression operates on each file as a separate stream, reducing its effectiveness for archives containing many small files. The format does support pluggable compression methods, but there's no straightforward way to support "solid" compression.
5) There is technically no way to reliably identify a ZIP file, as the end of central directory record can appear at any location near the end of the file, and the file can contain arbitrary data at its start. Most tools recognize ZIP files by the presence of a local file header at the start ("PK\x01\x02"), but that's not reliable.