René Scharfe:
I struggled with that sentence as well. There is no explicit
"format" field AFAICS.
Exactly. I interpret that as it is in zip64 format if there are any
zip64 structures in the archive (especially if there is a zip64
end of central directory locator).
Or in other words: A legacy ZIP archive and a ZIP64 archive can be
bit-wise the same if all values for all entries fit into the legacy
fields, but the difference in terms of the spec is what the archiver
was allowed to do when it created them.
As long as all sizes are below (unsigned) -1, then they would be
identical. If one, and only one, of the sizes are equal to (unsigned)
-1 (and none overflow), then it is up to intepretation whether or not
a ZIP64-aware archiver is allowed to output an archive that is not in
ZIP64 format. If any single size or value overflows the 32 (16) bit
values, then ZIP64 format is needed.
# 4-byte sizes, not ZIP64
arch --format=zip ...
# ZIP64, can use 8-byte sizes as needed
arch --format=zip64 ...
Makes sense?
Well, I would say that it would be a lot easier to always emit zip64
archives. An old-style unzipper should be able to read them anyway if
there are no overflowing fields, right? And, besides, who in 2017 has
an unzip tool that is unable to read zip64? Info-Zip UnZip has
supported Zip64 since 2009.
--
\\// Peter - http://www.softwolves.pp.se/
