support ZIP64 for zipfiles larger than 4GB

[thejoshwolfe]

[thejoshwolfe]

notes for implementing:

• Include section 4.3.14 Zip64 end of central directory record
  • zip64 extensible data sector should always be empty.
• Include section 4.3.15 Zip64 end of central directory locator
• For any "normal" format value that has a ZIP64 counterpart (e.g. "offset of start of central directory with respect to the starting disk number"), the normal format value must be correct unless the value is out of bounds for the normal format, in which case it must be set to the max value (e.g. 0xFFFFFFFF).
• Set version needed to extract to 0x2d instead of 0x14.
• For file entries (both central and local), include a 4.5.3 -Zip64 Extended Information Extra Field (0x0001) only if one of the fields doesn't fit into the normal format.
  • Only make the extra field as long as it needs to be to include the necessary information. We will never need the whole thing, because we never need to specify the last field which talks about disc numbers.
• If a 4.5.3 -Zip64 Extended Information Extra Field (0x0001) is used for a file entry, its corresponding 4.3.9 Data descriptor uses 8 bytes instead of 4 bytes for each of its compressed and uncompressed size.

[thejoshwolfe]

See #20 for trouble supporting this issue.

[thejoshwolfe]

New plan: add an option for addFile() and friends: options.zip64:

• false (default) no ZIP64 support--status quo.
• true uses ZIP64 format with general purpose bit 3 (regardless of whether ZIP64 format is actually required). Note that this will produce zip files that cannot be interpreted by Mac's Archive Utility (see API for random access output #20).
• "auto" effectively chooses true or false above by querying the size of the file and/or counting how many addFile()-like methods have been called so far. Note that this may cause delays in the output data near the beginning while yazl waits for fs.fstat() to report how large the file is.

This is not a perfect solution. With this idea, there is no way to create ZIP64 archives that Mac's Archive Utility can understand. But at least yazl users can create ZIP64 archives if they want them, and yazl's backward compatibility is preserved.

[thejoshwolfe]

New plan: we can just use ZIP64 format when we need it, and the only zip reader i've found that this breaks is Archive Utility, which doesn't support ZIP64 at all anyway. In other words, this issue is relatively easy. No zip file reader is motivating any compromise to yazl's design.