gh-103861: Fix Zip64 extensions not being properly applied in some cases

[pR0Ps]

This commit fixes an issue where adding a small file to a ZipFile object while forcing zip64 extensions causes an extra Zip64 record to be added to the zip, but doesn't update the min_version or file sizes.

To create a file that reproduces the issue (copied from #103861):

import zipfile

with zipfile.ZipFile("out.zip", mode="w", allowZip64=True) as zf:
    with zf.open("text.txt", mode="w", force_zip64=True) as zi:
        zi.write(b"some data")

Diff of information extracted by zipdetails from running the above script before and after this commit.

 0000 LOCAL HEADER #1       04034B50
-0004 Extract Zip Spec      14 '2.0'
+0004 Extract Zip Spec      2D '4.5'
 0005 Extract OS            00 'MS-DOS'
 0006 General Purpose Flag  0000
 0008 Compression Method    0000 'Stored'
 000A Last Mod Time         00210000 'Mon Dec 31 19:00:00 1979'
 000E CRC                   D9C2E91E
-0012 Compressed Length     00000009
-0016 Uncompressed Length   00000009
+0012 Compressed Length     FFFFFFFF
+0016 Uncompressed Length   FFFFFFFF
 001A Filename Length       0008
 001C Extra Length          0014
 001E Filename              'text.txt'
 0026 Extra ID #0001        0001 'ZIP64'
 0028   Length              0010
 002A   Uncompressed Size   0000000000000009
 0032   Compressed Size     0000000000000009
 003A PAYLOAD               some data

 0043 CENTRAL HEADER #1     02014B50
-0047 Created Zip Spec      14 '2.0'
+0047 Created Zip Spec      2D '4.5'
 0048 Created OS            03 'Unix'
-0049 Extract Zip Spec      14 '2.0'
+0049 Extract Zip Spec      2D '4.5'
 004A Extract OS            00 'MS-DOS'
 004B General Purpose Flag  0000
 004D Compression Method    0000 'Stored'
 004F Last Mod Time         00210000 'Mon Dec 31 19:00:00 1979'
 0053 CRC                   D9C2E91E
 0057 Compressed Length     00000009
 005B Uncompressed Length   00000009
 005F Filename Length       0008
 0061 Extra Length          0000
 0063 Comment Length        0000
 0065 Disk Start            0000
 0067 Int File Attributes   0000
      [Bit 0]               0 'Binary Data'
 0069 Ext File Attributes   01800000
 006D Local Header Offset   00000000
 0071 Filename              'text.txt'

 0079 END CENTRAL HEADER    06054B50
 007D Number of this disk   0000
 007F Central Dir Disk no   0000
 0081 Entries in this disk  0001
 0083 Total Entries         0001
 0085 Size of Central Dir   00000036
 0089 Offset to Central Dir 00000043
 008D Comment Length        0000

A test has also been added that checks that these properties are correctly set.

• Issue: Writing a small file into a ZipFile while forcing zip64 extensions results in an incorrect zip file #103861

Potential reviewer based on the git blame of the changed lines: @serhiy-storchaka (182d7cd)
Potential reviewers based on the experts index: @Yhg1s, @gpshead

[gpshead]

I think this is the issue you were talking about at lunch today? (yay pycon sprints!)

[pR0Ps]

Yep, that's this one!

[pR0Ps]

@gpshead Addressed review comments

[gpshead]

github actions CI infrastructure seems broken at the moment. But I think this the PR is ready.

I undid one part of your change so it'd remain a pure bugfix: ZipInfo.FileHeader() is technically a public API - even if it seems like nothing should use it we must assume someone does. So getting rid of the old zip64=None default behavior would be an API change, so I restored that. But it should be a no-op as FileHeader is always called with an explicit zip64 bool supplied within the zipfile module itself.

I'll take another look later and rerun CI after it's healthy again.

[miss-islington]

Thanks @pR0Ps for the PR, and @gpshead for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

[miss-islington]

Sorry, @pR0Ps and @gpshead, I could not cleanly backport this to 3.11 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 798bcaa1eb01de7db9ff1881a3088603ad09b096 3.11

[bedevere-bot]

GH-104534 is a backport of this pull request to the 3.11 branch.