[FEATURE] Support ZIP64

As discussed on the roadmap and in #12, ZIP64 support is a highly desirable improvement for client-zip as it allows the creation of ZIP files larger than 4GB and containing files larger than 4GB themselves.

Once implemented, ZIP64 output would be the default for client-zip. That is consistent with other ZIP libraries, and the overhead is negligible. Making it the default is a slightly breaking change, but ZIP64 justifies a major version bump anyway.

Update 1:

While BigInts themselves — flawed though they may be — are finally available in browsers, the BigInt64 ArrayBuffer features have not yet landed in all browsers. But they can be polyfilled quite easily (actually I only need one: DataView.setBigUint64).

So that’s what I’m going to do. The plan is to release client-zip 2.0 soon, with ZIP64. However, it will only work in browsers that support BigInts.

Update 2:

I just got the wrong byte order for the Zip64 extra field signature…

Update 3:

After some hexdumping and reverse-engineering of Zip64 files, I got client-zip to make valid ones too (or at least, files that 7zip and unzip don’t complain about).

[Owpac]

To give you some feedbacks, I tested version 1.3.0 and 2.0.0-rc2 with a 5,63Go file. I’m on a Macbook Pro M1, with an implementation of client-zip with Stream Saver. I’m also using the default Mac unarchiver.

On v2.0.0-rc2, everything seems to work perfectly thanks to your integration of Zip64 format. On v1.3.0, I successfully downloaded my file in a zip, but I can’t extract it without an error which is normal since Zip32 can’t support file over 4Go.

[Touffy]

Actually, it works now — as far as I can tell. I was waiting for some feedback from other users to release version 2.0.0 but you can get version 2.0.0-rc2 already with Zip64 (and tell me if you happen to make a corrupted archive with it).

Thanks for the link. I’ll make sure I haven’t missed something.