p7zip error 2 on extracting big files over 4GB

[aonez]

As commented on #15 by @benungs:

I received the same error today, on OS X El Capitan. It was a huge file, 9.42GB, and was uploaded on a mac with Dropbox (presumably zipped OS X native, but that's a guess), downloaded via Firefox. Same as entusductus, I was able to unzip it with the OS X's native archive utility. I tried it with Keka version 1.0.7 (latest stable release) and the beta version (1.1.0b1r1827), both with the same 'Error Code 2 using "p7zip" Fatal error' message.

Again, these unzip properly with the native OS X archive utility. I think it's a size issue. I'm going to run some tests with different file sizes.

It looks like Keka struggles with zipped files over 4GB. Here you can find two files zipped with OS X's Archive Utility; one slightly over 4GB, the other slightly under 4GB. The smaller one unzips; the larger one fails.

Here a test file: big.7z.zip

The first zip (so GitHub accepts the file) contains a 7z file that contains the big and corrupt zip. Thanks to Igor for the steps to this wonderful little big thing.

[aonez]

I've managed to replicate the issue, creating zip files with the bundled mac archiver. Those created with Keka work.

[aonez]

Seems like macOS system is creating corrupt files if they are bigger than 4GB. Already reported a bug to Apple.

[aonez]

Though its not really a p7zip fail but a corruption in macOS (and earlier, tested Mac OS X 10.9), maybe Igor Pavlov can enlighten us: https://sourceforge.net/p/sevenzip/bugs/2038

[benungs]

Why is the native Archiver still able to unzip it when it is a corrupt file?

[aonez]

Also unzip (via Terminal) can extract its contents, not without throwing some warnings of data corruption. WinZip is unable of opening the file, and WinRAR extracts it also throwing some corruption messages.

[klou]

I just got this error with a *.7z I just created with 1.0.7 (maximum compression). The archive itself is about 18 MB.

Got the error when attempting to unpack with 1.0.7 and 1.0.8. However, was able unpack via p7zip 16.02 directly ("7z x *.7z") on CentOS.

[aonez]

@klou this seems to be another issue, since this one just affects files bigger than 4GB. Is it possible to you to share the file?

[ejm554]

FWIW, I encountered a similar issue (or something similar) on El Capitan too. But it happened with an 11.75 GB file zipped by Keka.

The compressed directory on my Mac was named "December 29, 1 (by Keka)". Below are the results of using the built-in/default Unzip utility from Terminal:

$ unzip -t "December 29, 1 (by Keka)"
Archive:  December 29, 1 (by Keka).zip
warning [December 29, 1 (by Keka).zip]:  7458748132 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error [December 29, 1 (by Keka).zip]:  start of central directory not found;
  zipfile corrupt.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)

Some research uncovered that El Capitan uses an outdated UnZip utility by Info-Zip, i.e., version 5.52, which doesn't support Zip64 files, a format created automatically when an archive begins to approach a 4 GB boundary. (See this answer on StackExchange.)

Upgrading to Info-Zip's UnZip version 6.00 via Homebrew and trying again showed that all was actually well with the archive:

$ unzip6 -t "December 29, 1 (by Keka)"
Archive:  December 29, 1 (by Keka).zip
    testing: December 29, 1/          OK
[...]
No errors detected in compressed data of December 29, 1 (by Keka).zip.

Note that I wanted to test the integrity of the Zip file, which is why I used the -t feature. I didn't want to perform a test by extracting the file to disk.

An aside: Have the Keka developers considered offering a test feature similar to what I was able to do above with UnZip?

[aonez]

An aside: Have the Keka developers considered offering a test feature similar to what I was able to do above with UnZip?

No timeline, but eventually sure #139

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hipunk]

Today I updated to 1.1.5 and this error happened to me with a 30,85 GB (according to Finder) large UDRO DMG source file I cannot share with you. Rolled back to 1.1.4 and it works flawlessly again. This has never occured to me before and I regularly use 7zip on files larger than 4 GB.
Just letting you know!

[kabir-jolly]

@hipunk I am also experiencing this issue, can't find 1.1.4 in the legacy files since it was relatively recent. How did you manage to roll it back? Thanks so much

[aonez]

@hipunk @kjolly02 could you enable the reader log and let me know what it says when the process fails?

defaults write com.aone.keka DevLog -bool true
defaults write com.aone.keka DevLogReader -bool true

@kjolly02 you'll always have all the releases here at GitHub, in Code -> Releases.

[jrallen9]

I can shed some light on this error. From my Mac environment after enabling logging (and searching console.app for 'keka') I found this error:

ERROR: stat error for /<omitted>/target/generated-sources/annotations/. (Permission denied)

Looks like the directory 'annotations' was missing the owner:execute bit (644).

[aonez]

Thanks a lot @jrallen9! Clearly this can be solved by improving the error messages displayed #116.

[v6]

// , I get the same error on a 104mb file. Why is this closed??