zip file I/O library for iOS, macOS and tvOS

Took me a while, as WinZip's way of using AES was a little different than what I'm used to. Also I changed the AES block processing code a few times... You may want to modify the git history to your liking ;-)

As described in some of the comments on #71, the mere inclusion of the zipzap CocoaPod in a project seems to have the effect of turning off support for Objective-C exceptions on a project-wide basis. For existing code and dependencies that are not easily altered, this is a blocker.

Earlier, I addressed the problem by ensuring a project-level setting was in force for GCC_ENABLE_OBJC_EXCEPTIONS = YES. After updating to CocoaPods 0.34.1 today and ensuring that a complete list of link_with targets are specified in my Podfile, this no longer works—the setting is superseded project-wide by zipzap.

As a further work-around, I moved this build setting to target-level on all affected targets in the project. While this now allows a build, it first creates a ton of spew when pod install is run:

[!] The `Kashoo [Development]` target overrides the `GCC_ENABLE_OBJC_EXCEPTIONS` build setting defined in `Pods/Target Support Files/Pods/Pods.development.xcconfig'. This can lead to problems with the CocoaPods installation
    - Use the `$(inherited)` flag, or
    - Remove the build settings from the target.

This message is repeated for every build configuration on every target (4 targets x 3 configurations = 12 warnings in my case).

At present Zipzap makes relatively little allowance for error-handling, which worries me:

• [x] In ZZFileChannel, the call to open might fail due to the URL being unsuitable, or a permissions problem. There is no way to indicate that to the caller beyond the likelihood of NSFileHandle blowing up
• [x] If writing data to the file handle fails midway through, NSFileHandle is documented to throw an exception. I don't think the code handles this at present, and users of Zipzap aren't advised that such a situation might arise
• [x] Also in ZZFileChannel, the -openInput method completely ignores the NSError object, so clients have no idea why it might have failed

In my app, I'd like to generate the data for a zip file entirely in-memory without touching the disk. The data is to be uploaded to a remote server, so there's no need for it to touch the local disk, and avoiding so means no file access errors can occur.

Looking through ZZMutableArchive, this looks a bit tricky to achieve. It seems the current code is built atop NSFileHandle. I could create a custom subclass of NSFileHandle that is backed by data, but that seems rather messy, and perhaps would fail in some places.

Using NSOutputStream instead would make my life easier. So, what in NSFileHandle are we dependent on? Looking at the code:

• -offsetInFile to track how much data has been written so far; this could be replaced by passing round integers as arguments/return values
• If an error occurs while writing an entry, winds the file handle back to where it was before that entry was written
• -truncateFileAtOffset called once writing is finished; as I understand it, that mostly is to handle archives which are now smaller than when they were read

Have I got those right, missed anything?

Hi there.

I am experimenting some crash when trying to unarchive a specific AES256 encrypted zip. The following invocation will crash:

decryptedStream = [[ZZAESDecryptInputStream alloc] initWithStream:dataStream password:password header:_localFileHeader->fileData() strength:_localFileHeader->extraField<ZZWinZipAESExtraField>()->encryptionStrength error:error]; }

This is because in some cases the _localFileHeader doesn't contain any data and as a result the encryptionStrength can't be extracted. I have found out that the file was corrupted but i believe we should return an error in this case.

I have now added this additional sanity check before the creation of the localFileHeader: nextCentralFileHeader->relativeOffsetOfLocalHeader == 0 && *beginContent == '\0

for the following section:

NSMutableArray<ZZArchiveEntry*>* entries = [NSMutableArray array];
    for (NSUInteger index = 0; index < endOfCentralDirectoryRecord->totalNumberOfEntriesInTheCentralDirectory; ++index)
    {
        // sanity check:
        if (
            // correct signature
            nextCentralFileHeader->sign != ZZCentralFileHeader::sign
            // single disk zip
            || nextCentralFileHeader->diskNumberStart != 0
            // local file occurs before first central file header, and has enough minimal space for at least local file
            || nextCentralFileHeader->relativeOffsetOfLocalHeader + sizeof(ZZLocalFileHeader)
                > endOfCentralDirectoryRecord->offsetOfStartOfCentralDirectoryWithRespectToTheStartingDiskNumber
            // next central file header in sequence is within the central directory
            || (const uint8_t*)nextCentralFileHeader->nextCentralFileHeader() > endOfCentralDirectory
            || nextCentralFileHeader->relativeOffsetOfLocalHeader == 0 && *beginContent == '\0')
            return ZZRaiseErrorNo(error, ZZCentralFileHeaderReadErrorCode, @{ZZEntryIndexKey : @(index)});

        ZZLocalFileHeader* nextLocalFileHeader = (ZZLocalFileHeader*)(beginContent
                                                                      + nextCentralFileHeader->relativeOffsetOfLocalHeader);

        [entries addObject:[[ZZOldArchiveEntry alloc] initWithCentralFileHeader:nextCentralFileHeader
                                                                localFileHeader:nextLocalFileHeader]];

        nextCentralFileHeader = nextCentralFileHeader->nextCentralFileHeader();
    }

What do you think? If this sounds correct to you i will make a pull request.

Thanks in advance for your input on that matter.

I've tried to install it with what you wrote on the README but I'm not doing it successfully. That would be nice to post a step-by-step picture 'tutorial'. Thank you

Zipzap has been changed to include a list of public headers in the podspec and the only one listed is zipzap.h. Unfortunately this means that the headers that one references aren't exported. Removing the public_headers line fixes the issue, but I'd assume adding the list of all headers an external project should be able to use would fix this too.

Steps to reproduce:

• Create a new project in Xcode
• Add a Podfile with zipzap listed as the only pod
• Run pod install
• Add the import for zipzap.h to any class in the project
• Build
• Observe error in zipzap.h: "ZZArchive.h file not found"

I see there's support for creating a ZZArchiveEntry that represents a directory, but have no idea how to actually populate it, or indeed find out its contents.

Hello,

My name is Josh and I have been using your library for some time. Firstly, I would like to say that it is fantastic.

Recently, I have had error reports from users, which I have worked this out to be something going wrong with our zipping code. Specifically, I am getting an ZZEndOfCentralDirectoryReadErrorCode from the ZipZap library.

I was wondering if you could explain what an End of Central Directory Read error is and in what circumstances it can occur.

Thanks in advance for any insights you can offer.

Cheers

Update podspec version from 6.0 to 6.1. Release version (tags) are mapped to a certain commit. 6.0 is mapped to 7fe656be30e550b97258579a6763a09c59bfd660

Cocoapods clones that commit in stead of c27f9e101eb545b464c16595fbac7c326203cc41 - the one that has the latest podspec and the AES encryption support.

Updating the podspec version to 6.1 and creating a new release (6.1) would allow CocoaPods to clone the correct version.

Hi, I'm building an iPhone app with support for iOS 6.0 and above.

Using Xcode 5, I'm getting the following error: "Invalid deployment target '6.0.0' for architecture 'arm64' (requires '7.0.0' or later)"

My guess is that the library is not deployed for iPhone 5s architecture.

Can anyone tell me how to import the ZipZap dependency into our XCode project without using Swift as there is no Swift package available?

Showing All Messages https://github.com/pixelglow/ZipZap.git has no Package.swift manifest

https://github.com/pixelglow/ZipZap/blob/master/ZipZap/ZZArchive.mm#L149

This line pointing to a static int sign: https://github.com/pixelglow/ZipZap/blob/master/ZipZap/ZZHeaders.h#L151

Should this be signature?

Hi,

When archiving ZipZap an empty archive is created. This can be remedied by setting the 'Build Setting' 'Skip Install' to 'No' for Release builds. Please consider this change.

Kind regards,

Remco Poelstra

Xcode has appletvsimulator12.0 installed and id:BD6947F6-C0D6-43C0-B35A-30C3F83A48CE matches

xcodebuild: error: Unable to find a destination matching the provided destination specifier:
		{ platform:tvOS Simulator, id:BD6947F6-C0D6-43C0-B35A-30C3F83A48CE }

	Ineligible destinations for the "ZipZap (tvOS Framework)" scheme:
		{ platform:tvOS, id:dvtdevice-DVTiOSDevicePlaceholder-appletvos:placeholder, name:Generic tvOS Device }
		{ platform:tvOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-appletvsimulator:placeholder, name:Generic tvOS Simulator Device }```