Extraction of 5GB (ZIP64) archive created with Go failed

[philip-firstorder]

Extraction of 5GB (ZIP64) archive created with Go Archiver: failed

The Unarchiver (4.1.0): There was a problem while reading the contents of "Go.zip": Data is corrupted => clicked Continue => Archive 5GB.zip is extracted, but not Small image.png

The Archive Browser (1.11.2)

=> Pressed OK and then this is what I see

I archived 2 blank files with ZIP Method: Storage

$ mkfile -n 5000000000 ~/Desktop/5GB_big_empty_file
$ mkfile -n 5000 ~/Desktop/5KB_small_empty_file

To reproduce please extract Go.zip.zip (5,9 MB) once to get Go.zip (5 GB) => then try to extract it with The Unarchiver (4.1.0) or open with The Archive Browser (1.11.2)

And here is the explanation on what went wrong from original issue #aonez/Keka#423

@PaulTaykalo
@aonez Knows the technical details and fixed it for Keka.

[philip-firstorder]

Here are some big 5GB sample archives created with Go, Keka and MacOS.

This is also the current detailed unarchiving status.

I already tested a release candidate of Keka unar (1.1.18) with this issue fixed.

[PaulTaykalo]

Well, it is more like this part is related to the fact that these changes are "broken"
https://github.com/MacPaw/XADMaster/blob/master/XADZipParser.m#L329

				off_t uncompsize64=[fh readUInt64LE];
				off_t compsize64=[fh readUInt64LE];
				off_t locheaderoffset64=[fh readUInt64LE];
				int startdisk64=[fh readUInt32LE]; <<<< (This is kinda optional, depending on the flags)
				if(uncompsize==0xffffffff) uncompsize=uncompsize64;

Will make a fix bit later. With this line commented out, unarchiving works fine

[philip-firstorder]

Yes, that's it, go and other archivers don't define the startdisk at all when it's not informed with 0xffff, this because it's also the last field so it can be safely ignored.

[aonez]

Already did the pull: #101

I'm using this fixed code for half a year now, it's safe.

[PaulTaykalo]

Fixed in 8662695