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/