Making zip archives that OS X can unzip

[gianlucabertani]

Making zip archives that OS X can unzip

[alexbell]

Experiencing this as well. Perhaps it's because this version includes its own ZLib? The Agile Bits repo of Objective-Zip uses the system provided one (among other differences) and works OK in this respect on OS X.

[mojtabacazi]

Make sure that you are closing the zip file when you are done:

[zipFile close];

[svintus]

Having the same issue, and I'm definitely calling [zipFile close]; This seems to be a regression. 0.8 works fine, 0.8.3 is broken.

[mojtabacazi]

I'm using 0.8.3 and it works fine! Could you upload 1-2 sample files some where so I can check see what's happening

[fparkar]

@mojtabacazi : You can check the version of code you have on github... just comment removeItemAtPath:filePath line in finally you have for test1()... This way you will have test1 file in Documents folder... Now try to double click on test.zip file and you will see it as test.zip.cpgz

[michaelmj]

These do unzip correctly with the command line "unzip", but they also fail with some other zip libraries I'm using (e.g. Exceed Zip). Using the built in zlib didn't fix this issue.

[mike-lischke]

I see this problem as well (using the latest code from Github). The zip file can be unzipped with the command line tool unzip as well as The Unarchiver, but not using the system archive utility. Would be great if you could give this some priority for fixing.

[eholzwarth]

Hi, I'm having the same problem, did anyone end up finding a solution? I'm using the AgileBits (built-in zlib) fork.

[fparkar]

@eholzwarth : I used https://github.com/soffes/ssziparchive. It works like charm...

[ufoq]

I fixed it changing zip64 parameter from 1 to 0 in calls to zipOpenNewFileInZip3_64 in writeFileInZipWithName ... methods in ZipFile. When zip64 is 1 it writes in header that version 4.5 is needed to decompress file that is too high for finder.

[dpr11]

@mUfoq : Ahah! Changing those calls does indeed seem to make the Finder unzip them. Great. Thanks.

[mike-lischke]

Will you create a pull request to have that fix in?

[ufoq]

Problem is that it is not fix, it is workaround. It's just like writing in metadata that we don't use zip64 features. If you want to make for example more than 4GB file and give it to finder, it wouldn't work.
Fixing it correctly should allow disabling zip64 from api or choose it dynamically by looking on features. My workaround is only for people that are sure that they make simple old zip file so it doesn't qualify for pull request.

[fparkar]

@mUfoq : just go with https://github.com/soffes/ssziparchive... It works perfectly...

[fparkar]

@mike-lischke : just go with https://github.com/soffes/ssziparchive its works perfectly...

[clueckler]

same issue here ... work with CLI but not with Extraction Programms. Windows Machines can unzip the files without any problems.

[abhibeckert]

@fparkar why do you keep telling people to use SSZipArchive? It's missing a whole bunch of important features that make it unusable for many projects.

[mgiraldo]

for those coming late to the thread, the “zip64 solution” means creating your zip like so:

OZZipFile *zipFile = [[OZZipFile alloc] initWithFileName:@"myFile.zip" mode:OZZipFileModeCreate legacy32BitMode:YES];