pixelglow/zipzap

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

zipzap's Issues

need to update Recipe(s for extracting an archive)

https://github.com/pixelglow/zipzap/wiki/Recipes

Sorry, i haven't looked as to whether or not the other Recipes should be updated because i'm not currently using them:/, though i'm guessing it's the case. should use updated API

in section:
Unzip an existing zip file to the file system:

code should be (something like)

  NSError* error = nil;

  [[entry newDataWithError:&error] writeToURL:targetPath
                   atomically:NO];
  if(error) {
    NSLog(@"%@",[error localizedDescription]);
  }

Error handling

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

• 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
• 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
• Also in ZZFileChannel, the -openInput method completely ignores the NSError object, so clients have no idea why it might have failed

ZipZap seems to require a .zip extension on new archives.

+[ZZArchive archiveWithURL:archiveURL error:error] seems to fail if archiveURL does not end with a ".zip" extension. It seems like it shouldn't care...? Is there a good reason for this?

Thanks.

Change log and versioning scheme?

Hi there,

We use zipzap in our project (it's great!). I noticed today that 7.0 is available in CocoaPods. Since it is important for me to be able to understand potential impacts and code changes required, I was trying to find a change log (as I do with all third-party components)—but could not. What has changed since 6.0?

I started comparing tags (6.0…7.0) in an effort to surmise, but then became confused about what I'm looking at. It appears that under every tag, the version number in the podspec is out of sync by one (e.g., tag 7.0 is actually version 6.0, tag 6.0 is version 5.0, etc.). What is the versioning scheme here?

thanks,

b

AES Encryption

If I can't find another Cocoa library that would have it built-in already I might start adding it myself but I'm also pretty sure you'd be faster doing it and it's a useful add-on. Let me know.

ZipZap available on iOS 4.3 ? (podspec >= 5.1)

The readme states "Run: Mac OS X 10.7 (Lion) or iOS 4.0 and later."

But the podspec specifies :

"s.platform = :ios, '5.1'"

Is there a version available for iOS 4.3 ?

Thanks,
Vincent

zip file format details

I originally posted this as part of another issue, as I was working my way through the reasoning for it in order to come to a final conclusion. Split out here as requested though:

OK, so first of all, let me make sure I've understood the layout of a zip file:

LocalFileHeader — includes dates, crc32, sizes, filename etc.
FileData — likely compressed, up to the archive generator, and specified in the header
DataDescriptor — also includes crc32 & sizes
repeat the above until you run out of files
CentralFileHeader — notes dates, sizes etc. of, I think, the overall archive?

The apparent duplication of LocalFileHeader and DataDescriptor strikes me as weird. From poking around zip archives I have here, it looks like LocalFileHeader generally reports file sizes to be 0. So I'm guessing unarchivers take that as a signal to consult the DataDescriptor for the true size of the file? Thus allowing a file to be rewritten into the archive without yet knowing the size it will be when compressed.

And then by waiting until the end of the archive to note the extra info associate with it, that also simplifies generation.

The bit I don't understand though, how do unarchivers know how to find the individual files and CentralFileHeader if each LocalFileHeader claims its data is of zero length?

• The compressed data can be easily analysed in some fashion to know when it stops
• The search is purely for an identifier, something like ZZDataDescriptor.signature. If so, how do you avoid hitting false positives inside of the compressed data?
• The CentralFileHeader contains knowledge of each file's length/location, and be consulted to work back and find the files. But if so, how do you find the central header itself?!

Does zipzap support password encryption?

My project needs the ability to delete/replace a file entry in an zip archive, but also need to support password. Does zipzap support password? If not, is it on the road map to support in a near future?

Any way to read an ArchiveEntry by fileName in an existing Zip?

Thanks!

gzip support

Hi,
I am trying to use the library with a .gz file and it does not seem to work. I ended up with an error code 1 (ZZEndOfCentralDirectoryReadErrorCode).

Is gzip supported?
If yes, is [ZZArchive archiveWithData:data] a correct way to use the lib for large files?

Thanks!

Installation advice

Might be a good idea to mention CocoaPods as an install method - I never had any success with the installation guides.

Fantastic piece of software!

zip multiple files

hi all,
for a few days i try to zip multiple files, but i get empty zip file, here is my code, can someone say if i do something wrong?
Thanks in advance!

- (IBAction)zipAll:(id)sender {

  NSString *documentsDirectory = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject];
    paths = [self recursivePathsForResourcesOfType:@"mp3" inDirectory:documentsDirectory];

    for (int i = 0; i < [paths count]; i++) {
        if (i==0) {
            ZZMutableArchive* newArchive = [ZZMutableArchive archiveWithContentsOfURL:[NSURL fileURLWithPath:[documentsDirectory stringByAppendingString:@"/last_zip.zip"]]];
            [newArchive updateEntries:
             @[
             [ZZArchiveEntry archiveEntryWithFileName:[[paths objectAtIndex:0]lastPathComponent] compress:NO dataBlock:^NSData *(NSError *__autoreleasing *error) {
                return [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[documentsDirectory stringByAppendingString:[NSString stringWithFormat:@"/%@",[paths objectAtIndex:i]]]]];
            }]
             ]
                                error:nil];

        }else{

            ZZMutableArchive* oldArchive = [ZZMutableArchive archiveWithContentsOfURL:[NSURL fileURLWithPath:[documentsDirectory stringByAppendingString:@"/last_zip.zip"]]];
            [oldArchive updateEntries:
             [oldArchive.entries arrayByAddingObject:
              [ZZArchiveEntry archiveEntryWithFileName:[paths objectAtIndex:i] compress:NO dataBlock:^NSData *(NSError *__autoreleasing *error) {
                 return [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[documentsDirectory stringByAppendingString:[NSString stringWithFormat:@"/%@",[paths objectAtIndex:i]]]]];
             }]
              ]
                                error:nil];

        }

    }

}

Having trouble immediately getting results

It took me a little while to realize that the [ZZArchive archiveWithData] may not immediately return a ZZArchive with entries.

what do you recommend as the best way to observe when entries is available with values?

Opening large archives on iOS yields "Cannot allocate memory" error from NSData

On some devices (but not all), attempting to open a large archive (> 500 MB) results in NSData falling to initialize using NSDataReadingMappedAlways with a "Cannot allocate memory" generic Cocoa error.

Apparently this is a known regression in iOS 7 that has not been fixed in iOS 8 (see http://openradar.io/14388203).

This prevents archives larger than this size to be read for decompression. One likely solution could be to modify behavior to use NSFileHandle for accessing the file data.

I can reproduce this issue on an iPod touch (5th gen) and iPad 3, but not an iPhone 5s.

static library compatible with device and simulator

Hi,

If i add the library and the headers to my project, i can build my project only if i use the same target as the one i used to build the library. I mean if i build the library with the target iOS >> Simulator and i import the .a and .h files to my project, my project will build only on the simulator. If i use the target iOS >> myDevice then it will work only if i build my project with a device target.
Is there any way to build a library wich will work with any target ?

zipping file error ,help!

hello,glen low:
i use zipzap to zip images and videos in my project .first i create a empty zip file and then add file to it one by one.
there are 200 images and videos to be zipped which total size is more than 800MB, the zip file which zipzap generate just contain a part of my files,only contain 60 files .i do not know why because there is no error.

NSArray *arr = [[NSFileManager defaultManager]contentsOfDirectoryAtURL:[NSURL fileURLWithPath:document] includingPropertiesForKeys:nil options:nil error:nil];
ZZMutableArchive *zip = [ZZMutableArchive archiveWithContentsOfURL:url];    
ZZArchiveEntry* readme = [ZZArchiveEntry archiveEntryWithFileName:@"readme.txt" compress:YES dataBlock:^NSData *(NSError *__autoreleasing *error) {
    return [@"hello,world" dataUsingEncoding:NSUTF8StringEncoding];
}];   
[zip updateEntries:@[readme] error:nil];
[arr enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    @autoreleasepool {
    NSURL *u = (NSURL*)obj;
    NSString *path = u.path;
    ZZArchiveEntry* tmp =[ZZArchiveEntry archiveEntryWithFileName:path.lastPathComponent compress:YES streamBlock:^BOOL(NSOutputStream *stream, NSError *__autoreleasing *error) {            
        NSFileHandle *handle = [NSFileHandle fileHandleForReadingAtPath:path];
        NSInteger iByteRead;
        NSInteger SIZE = 1024*1024*2;
        do {
            @autoreleasepool {
                NSData *data = [handle readDataOfLength:SIZE];
                iByteRead = data.length;
                if (data.length > 0) {
                    const uint8_t* bytes;
                    NSInteger bytesLeft = 0 ,bytesWritten = 0;
                    for (bytes = (const uint8_t*)data.bytes, bytesLeft = data.length;bytesLeft > 0;bytes += bytesWritten, bytesLeft -= bytesWritten){
                        bytesWritten = [stream write:bytes maxLength:MIN(bytesLeft, SIZE)];
                        if (bytesWritten == -1){
                            if (error)
                                *error = stream.streamError;
                            return NO;
                        }
                    }
                }
            }
        } while (iByteRead > 0);
        [handle closeFile];
        return YES;
    }];
        BOOL flag = [zip updateEntries:[zip.entries arrayByAddingObject:tmp ]  error:nil];
        NSLog(@"current:%i------------status:%@",idx,(flag == YES ?@"YES":@"NO"));
    }
}];

Unrecognized Selector

Excellent install instructions, thank you. However, when I try to create a new zip file, it says:

-[ZZArchive setEntries:]: unrecognized selector sent to instance 0xc33ea50

Compilation error on "Release" configuration

Hi,

I was able to run my app with zipzap on Development mode, but when I try to archive for release it fails due to "'zipzap/zipzap.h' file not found"

Any ideas?

Gil

Does zipzap support progress callback?

Hey guys,

Does zipzap or will support the progress callback via delegate, block or something?

It would be OK for UI

Thanks

Compile / ZZArchiveEntry issue

I just transferred a project that was successfully using zipzap in the past to a new computer. After re-integrating a fresh download of zipzap with the project, I'm getting an ARC error on compile. I'm sure it's a simple issue, but I've been bashing my head on it for several hours with no success.

The error:
No visible @interface for 'ZZArchiveEntry' declares the selector 'newData'

Basically, this code utilizes the same snippet as seen in the recipes:

if (!(entry.fileMode & S_IFDIR))
[[entry newData] writeToURL:targetPath
atomically:NO];
and the error is highlighting the entry code. It used to work...I haven't changed the code. However, I can't figure out what I've linked wrong. Any ideas?

XCode profiler throws errors processing ZZHeaders.h

I think this is because it's treating ZZHeaders.h as a C header file, not a C++ header file.

Can't build a fat library (iOS + simulator)

I downloaded the code and I'm trying to build a fat library using XCode 5.1. The build process is OK, but I don't seem to find a library that works for both an iOS device and the simulator.

I also tried creating a new project using the source code. I added an aggregate target in this project to build the fat library. However, I can build a library that compiles for iOS device, but doesn't compile for the simulator.

In both instances, I get these errors when compiling for the simulator:
Undefined symbols for architecture i386:
"std::terminate()", referenced from:
___clang_call_terminate in libzipzap.a(ZZArchive.o)
___clang_call_terminate in libzipzap.a(ZZNewArchiveEntryWriter.o)
___clang_call_terminate in libzipzap.a(ZZOldArchiveEntry.o)
"___cxa_begin_catch", referenced from:
___clang_call_terminate in libzipzap.a(ZZArchive.o)
___clang_call_terminate in libzipzap.a(ZZNewArchiveEntryWriter.o)
___clang_call_terminate in libzipzap.a(ZZOldArchiveEntry.o)
"___gxx_personality_v0", referenced from:
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZNewArchiveEntryWriter.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZOldArchiveEntry.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZNewArchiveEntryWriter.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZOldArchiveEntry.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZNewArchiveEntryWriter.o)
Dwarf Exception Unwind Info (__eh_frame) in libzipzap.a(ZZOldArchiveEntry.o)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Podfile excluding headers

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"

Document how to work with directories

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.

Streaming Issue

Hi,
The following is the suedocode to stream in the 512 bytes from the ZZInflateInputStream.

    NSInteger bytesRead;
    NSUInteger chunkSize = (archiveEntry.uncompressedSize < 512) ? archiveEntry.uncompressedSize : 512;
    NSMutableData *streamData = [NSMutableData data];
    do {
        streamData.length = chunkSize;
        bytesRead = [inputStream read:(uint8_t *)streamData.mutableBytes maxLength:chunkSize];
        bytesRead = (bytesRead < 0) ? 0 : bytesRead;
        if (bytesRead != 0) {
            [destinationHandle writeData:streamData];
        }
    } while (bytesRead);

For the stream
NSInputStream *inputStream = nil;

In earlier zipzap version:
inputStream = archiveEntry.newStream;

In newer zipzap version:
if (password) {
inputStream = [archiveEntry newStreamWithPassword:password error:&error];
} else {
inputStream = [archiveEntry newStreamWithError:&error];
}

Sorry I couldn't attach the zip file here. Can you please download it from the mail.

ZZArchiveEntry: fix docs for data to newData change

Hi --

At least for two places, the old data is used instead of newData, as the modifications done in 7fe656b hasn't been rolled out to the docs:

• http://pixelglow.github.io/zipzap/api/Classes/ZZArchiveEntry.html#instance_methods
• https://github.com/pixelglow/zipzap/wiki/Recipes (the second one)

Could you please fix this? Thanks :)

Compile as framework for OSX

Hi. I know this is problem I probably created myself but I thought it may be useful to ask if you have any suggestions for how to solve it. I compiled zipzap (source cloned as of today) as a framework. I only allow valid architecture to be X86_64 and it compiles successfuly. I copy the headers to the framework in build phases. I then try to link the framework in my OSX app which is X86_64 and i get the error:

Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_ZZArchiveEntry", referenced from: objc-class-ref in SDAppDelegate.o "_OBJC_CLASS_$_ZZMutableArchive", referenced from: objc-class-ref in SDAppDelegate.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

Is there any setting in zipzap project I need to change to avoid other than X86_64 to be compiled that I may have missed? I wonder if the framework contains some other architecture which confuses my project. Thanks for a great library and thanks for your help. Cheers, Trond Kristiansen

First item not added to ZZMutableArchive

Hi. Thanks for a great framework! I have an issue where I am looping over an array of files and adding each item to ZZMutableArchive. The first item is never included in the zip file. To solve the issue I am making a 'fake' call to the first item, but this does not seem like a viable solution. My code looks like this:

// Fake call
NSMutableArray *files = [self excludeDirectoriesInArray:self.myenum.allObjects];
numberOfFilesToZip=files.count;

ZZMutableArchive* newArchive = [ZZMutableArchive archiveWithContentsOfURL:myzipfile];

[newArchive updateEntries: [newArchive.entries arrayByAddingObject:

                            [ZZArchiveEntry archiveEntryWithFileName:[[files objectAtIndex:0] path] compress:YES
                                                           dataBlock:^NSData *(NSError *__autoreleasing *error)
                             {
                                 return nil;
                             }]]
                            error:nil];
 //End fake call
for (NSURL *myurl in files){

    NSNumber *isDirectory;
    [myurl getResourceValue:&isDirectory forKey:NSURLIsDirectoryKey error:nil];

    if (![isDirectory boolValue]){
        [newArchive updateEntries: [newArchive.entries arrayByAddingObject:

          [ZZArchiveEntry archiveEntryWithFileName:myurl.path compress:YES
                                         dataBlock:^NSData *(NSError *__autoreleasing *error)
           {
               NSData *mydata=[NSData dataWithContentsOfURL:myurl];
               return mydata; 
           }]]
                            error:nil];
     }
  }
}

Do you have any suggestions as to what i am doing wrong initializing the ZZMutableArchive or how I can avoid making the extra 'fake' call for initiation? Thanks! Cheers, Trond

Write-ahead Logging

I've moved this over from #9 to its own issue

We want to have some form of WAL to avoid zip file corruption on writing out data. At this stage I'm not sure whether I want to make it explicit in the API -- which adds to cognitive overhead for using zipzap -- or try for a transparent solution which can fail in common edge cases like some other process or event changing the zip file between recording the WAL and reapplying the WAL.

Since @79f31f7, we write first to temp files (or data) then attempt to apply the temp files to the original file. This temp file could serve as a WAL with some sort of link from the original to the temp file e.g. via xattr. If and when the app crashes when applying the temp file, the link will still be present and can be automatically applied when the file is opened again.

This should be configurable via init parameters for users that don't want the overhead of a WAL.

Would appreciate your thoughts and feedback!

Not being able to install zipzap on my project

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

PodSpec iOS requirement does not match with readme

The readme file says minimum iOS version is 4.0+
podspec file however lists minimum iOS version is 5.1.

Can someone update the appropriate file to reflect the requirements accurately?

Remove the distinction between mutable and immutable archives

In Cocoa, an immutable object is one whose contents cannot change.

For example, an immutable array holds a unchanging list of objects. Yes, properties etc. of those objects might change, but the actual objects referred to does not.

And again NSData consists of a pointer (to some bytes) and a length. Neither of those can change. In rare setups, the memory pointed to can change, but the NSData object itself does not.

ZZArchive follows a similar pattern, having a mutable subclass, but oddly does not adhere fully; a regular ZZArchive can be mutated at any time by calling the -load: method.

There is little to advantage to having a truly immutable archive; unlike arrays and strings etc. apps do not tend to pass them around too much internally (particularly when memory mapping means entries can have their content changed out underneath them anyhow).

Thus I argue there is no point in having ZZMutableArchive as a separate class. ZZArchive should be mutable, and that would be it. For apps that do feel the need to pass around archives internally, it's simpler to just agree not to mutate it, or define a protocol and pass around objects promising only that they conform to it.

[ZZInflateInputStream decompressData:withUncompressedSize:] never calls inflateEnd

https://github.com/pixelglow/zipzap/blob/master/zipzap/ZZInflateInputStream.m#L42

After the data is inflated, [ZZInflateInputStream decompressData:withUncompressedSize:] doesn't call inflateEnd(&stream); which leads to a buffer of size uncompressedSize never de-allocated.

Can I zip data from string?

I made some code like this:

NSString str = @"The zip file is an ideal container for compound Objective-C documents. Zip files are widely used and well understood. You can randomly access their parts. The format compresses decently and has extensive operating system and tool support. So we want to make this format an even easier choice for you. Thus, the library features:";
NSData *tmpData = [str dataUsingEncoding:NSUTF8StringEncoding];
ZZArchive oldArchive = [ZZArchive archiveWithData:tmpData];
ZZArchiveEntry* firstArchiveEntry = oldArchive.entries[0];
NSData *data =[firstArchiveEntry newData];

but the Entry is always nil, how I solve it?

ZZArchive archiveWithURL: always returns nil with no error.

In ZZArchive.mm line 87: b59b5e7

Options is nil and so createIfMissing is always false.

if (createIfMissing && ![self loadCanMiss:createIfMissing.boolValue error:error])

This at least got it working for me again. Am I missing something? This code was previously using the ZZMutableArchive class.

File Mode issue with zip created in windows system

I am extracting the zip files which are created in windows system. To identify the folders inside the zip, I am using if (archiveEntry.fileMode & S_IFDIR) condition.
But I create a zip file out of a folder, which has few folders inside, in windows system, the fileMode for the ZZArchiveEntry entries is 0. Is there any way to identify the directory in these cases?

Use of zipzap CocoaPod disables exception support project-wide

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).

Publish v6.0 on Cocoapods

Would you agree to let me publish the v6.0 of zipzap on the official Cocoapods spec repository?

Identifying wrong password in standard PKZip decryption

Hi,

I'm integrating zipzap for unzipping password protected files. If user enters wrong password, I'm showing an alert box where he can enter the password again.

In case of standard decryption (ZZEncryptionModeStandard), I didn't find a way to identify wrong password. For WinZip decryption, I'm relying on ZZWrongPassword error code.

However, when password is wrong, in -[ZZOldArchiveEntry newDataWithPassword: error:], totalBytesRead is zero and returned data has all zeros filled in it. Can I use this as an indication of wrong password or is there any other way?

Error adding big file to archive

I'm getting this error when adding a large file to an archive:

Error Domain=com.pixelglow.zipzap Code=5 "The operation couldn’t be completed. (com.pixelglow.zipzap error 5.)" UserInfo=0x1fdb9c60 {NSUnderlyingError=0x1fdb9cc0 "The operation couldn’t be completed. (Cocoa error 256.)", ZZEntryIndexKey=4} 

My code looks like this:

ZZArchiveEntry *entry = [ZZArchiveEntry archiveEntryWithFileName:filename.lastPathComponent
                                                        compress:NO
                                                       dataBlock:^(NSError **error) {
    return [NSData dataWithContentsOfFile:filename options:NSDataReadingMappedIfSafe error:error];
  }];
[archive updateEntries:[archive.entries arrayByAddingObject:entry] error:&error];

I have plenty of other smaller files that I add just fine. The next biggest file is 50 mb, and I can add that one too without issues. The file in question is a 367 mb webcam recording (.mov). I've been able to add smaller webcam recordings before.

Sometimes it fails right away, and sometimes it takes a few minutes before it fails. Any idea what could be going wrong?

Zero zip file size bug fix

Added in method - (BOOL)load:(NSError**)error module ZZArchive
after row
if (!contents)
return ZZRaiseError(error, ZZOpenReadErrorCode, @{NSUnderlyingErrorKey : readError});

if (contents.length == 0) {
    _contents = contents;
    _entries = [NSArray new];
    return YES;
}

Needs more documentation on how to manage memory during unzip.

Following the recommended code snippet on IOS for 141 MB zip file quickly crashed my app due to memory issues.

Not remove right tempory dir. Add all folder in path into zip file

Hi!

I wrote an example and run it on simulator.
I found that ZipZap don't remove old temporary dir it used!
(Exactly, I saw removeTemporaries method in "ZZFileChannel.m" and this temporaryDirectory is not the same with temporary dir it used!)

NSFileManager* fileManager = [NSFileManager defaultManager];
NSURL* temporaryDirectory = [fileManager URLForDirectory:NSItemReplacementDirectory              inDomain:NSUserDomainMask
                                       appropriateForURL:_URL
                                                  create:NO
                                                   error:nil];
if (temporaryDirectory)
    [fileManager removeItemAtURL:temporaryDirectory error:nil];
}

When I used the following code, app created a zip file include all folder in destination path. (You can see it at here: https://www.dropbox.com/s/gtbcbibgcp8280i/abcxyz.zip)

ZZMutableArchive* newArchive = [ZZMutableArchive archiveWithContentsOfURL:[NSURL fileURLWithPath:@"/Users/MyUser/Library/Application Support/iPhone Simulator/6.0/Applications/49CD93C6-6C88-488C-8062-8493E5756456/Documents/zipzap/abcxyz.zip"]];

NSError *err;
NSString *pathFile = [[NSBundle mainBundle] pathForResource:@"photo" ofType:@"jpg"];
BOOL result;
for (int i= 1; i < 2; i++) {
    result = [newArchive updateEntries:@[
              [ZZArchiveEntry archiveEntryWithFileName:pathFile
                                              compress:NO
                                             dataBlock:^NSData *(NSError **error) {
                                                 return [@"hello, world" dataUsingEncoding:NSUTF8StringEncoding];
                                             }]]
                                 error:&err];
    if (!result) {
        NSLog(@"%@",err.localizedDescription);
    }
}

Could you fix them?

Unable to unzip own files

Hi there.

I just integrated zip zap in our core, it usually works, but some of the files zipped by zipzap cannot be unzipped again, by zip zap. Ironically OSX can unzip the files without issues.

I set up a simple test project to display the issue of one of the files in question. You can find it here:
https://wallmob.box.com/s/nt9q6yfmhqlnl574823q

Xcode 5 arm64 error

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.

Exception creating an error in -[ZZArchive updateEntries:error:].

I'm getting the following error when attempting to archive an item:

10/16/14 11:30:53.011 AM <censored>[20049]: (
0   CoreFoundation                      0x00007fff86d8325c __exceptionPreprocess + 172
1   libobjc.A.dylib                     0x00007fff834ade75 objc_exception_throw + 43
2   CoreFoundation                      0x00007fff86c82dd1 -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 385
3   CoreFoundation                      0x00007fff86c98ad9 +[NSDictionary dictionaryWithObjects:forKeys:count:] + 57
4   Sync                                0x000000010a34ed93 -[ZZArchive updateEntries:error:] + 1971
5   Sync                                0x000000010a22c104 DTSArchiveOfFilesAtURLs + 900
6   Sync                                0x000000010a22d736 DTSArchiveOfItemAtURL + 518
7   Sync                                0x000000010a22dce1 __DTSArchiveItemAtURL_block_invoke + 97
8   libdispatch.dylib                   0x00000001009dd32d _dispatch_call_block_and_release + 12
9   libdispatch.dylib                   0x00000001009d9925 _dispatch_client_callout + 8
10  libdispatch.dylib                   0x00000001009dbc3d _dispatch_root_queue_drain + 601
11  libdispatch.dylib                   0x00000001009dd2e6 _dispatch_worker_thread2 + 52
12  libsystem_pthread.dylib             0x00007fff87f18ef8 _pthread_wqthread + 314
13  libsystem_pthread.dylib             0x00007fff87f1bfb9 start_wqthread + 13
)

Evidently the call at ZZArchive.mm:218 to -[ZZNewArchiveEntryWriter writeLocalFileToChannelOutput:withInitialSkip:error:] failed but didn't return an error.

If there's anything I can do to help troubleshoot, please let me know.

Add to iOS project without relying on Workspace

Is there a way to add this to an existing project that does not have an Xcode workspace set up? I'd like to include without having to set up a workspace as it will disrupt an automated build system that's in place. I.e. by including the ZipZap source directly. I imaging there are particulars to including ObjC++, I've never dealt with this sort of thing and figured I'd ask. Thanks!

Trouble replacing an existing entry in a zip file.

Hi Glen,

I am attempting to update an existing entry in an archive using the following code.

Basically, I start by reading the entry into an NSData object, I make the change to the object, and then read it back into an updated entry...

ZZArchiveEntry *updatedEntry = [ZZArchiveEntry archiveEntryWithFileName:entryFileName compress:YES dataBlock:^(NSError **error) {
     return entryData;
}];

[archive updateEntries:@[updatedEntry] error:&error];

This works perfectly fine, but it does not overwrite the existing entry. Instead, it creates a new entry with "_1" appended. I know this is by design, but I can't figure out based on the documentation how to replace the existing entry (or even remove it first and then add the updated entry to "replace" it).

I would appreciate any help you can provide.

-William

In-memory zip generation

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?

(entry.fileMode & S_IFDIR) > 0 always false.

While using this library in a custom Swift framework, I found the problem that, when trying to unzip a file, the following validation was always false...

(entry.fileMode & S_IFDIR) > 0 // Entry is Directory.

In the fileMode method switch, it goes to the ntfs option,

• (mode_t)fileMode
  {
  uint32_t externalFileAttributes = _centralFileHeader->externalFileAttributes;
  switch (_centralFileHeader->fileAttributeCompatibility)
  {
  case ZZFileAttributeCompatibility::msdos:
  case ZZFileAttributeCompatibility::ntfs:
  // if we have MS-DOS or NTFS file attributes, synthesize UNIX ones from them
  return S_IRUSR | S_IRGRP | S_IROTH
  | (externalFileAttributes & static_cast<uint32_t>(ZZMSDOSAttributes::readonly) ? 0 : S_IWUSR)
  | (externalFileAttributes & (static_cast<uint32_t>(ZZMSDOSAttributes::subdirectory) | static_cast<uint32_t>(ZZMSDOSAttributes::volume)) ? S_IFDIR | S_IXUSR | S_IXGRP | S_IXOTH : S_IFREG);
  case ZZFileAttributeCompatibility::unix:
  // if we have UNIX file attributes, they are in the high 16 bits
  return externalFileAttributes >> 16;
  default:
  return 0;
  }
  }

and the externalFileAttributes is always nil... is it possible that this is because of how the zip file got generated? It works fine when unzipping via Terminal.