You can clone with
HTTPS or Subversion.
I have a web app where I use nginx + mod_zip (HEAD version of repo).
Every zip created with mod_zip give me an 'Error- 1 Operation not permitted' error when I use the default unarchiver from Mac OS, using StuffIt expander solves this issue.
Any reason why these zips cannot be unarchived using the default tool?
Yes actually, the nature of this problem has to do with a common misinterpretation of the zip spec.
The problem stems from the presence of an unnecessary data descriptor (between the file data and the central directory structure), which is really only needed when the 3rd bitflag is set.
Seeing as I'm going to be using this mod soon, I'll email the maintainer and see if I can help get this fixed, I'm not proficient enough at C to submit a patch myself.
I'd like to report that we've observed this on our application as well. Bizarrely enough, it only occurs for certain specific files (which I can't attach because they're confidential). Those are architecture PDFs which cause the issue whether they're included unchanged, or opened in Preview and saved again, or even rotated before saving. It doesn't occur with other files, or other PDFs, just with those specific ones.
Anyway, would be great to get this fixed! (no idea what the problem is though)
Did you guys ever figure out an alternative solution? Ran into this same issue while prototyping and unfortunately it means we're at a dead end with mod_zip.
I am having same error but in my case I get a few bytes of zipped file from 100s of MBs of data. I have created a location using a 3rd party module https://github.com/anomalizer/ngx_aws_auth to get s3 files and using it to set files for mod_zip. That location is working fine if I use it directly.
Just ran into this myself. No patches for this, yet?
Although....seems to be sovled as long as you specify the CRC32 in the archive file manifest.
Apologies for the delayed follow up to my previous comment here. I've been working on this issue privately in the time since my last comment.
Firstly, my initial assessment was incorrect, the ZIP files generated by this module appear to match up with what the specification says is allowed.
The specific compatibility problem was rooted in the fact that Archive Utility (BOMArchiveHelper) had very buggy support for ZIP file trailers.
Now the obvious solution to this is to not include the file trailer, this is perfectly doable, but only if the CRC32 is included, something which this module already handles correctly as other people have already noted. Code
To my knowledge there is no variation of a ZIP file that allows both the trailer and the CRC32 to be omitted, leaving us with a situation where there is absolutely no possible output we can generate in that case that will be valid for Archive Utility. As a result of this realization I got in touch with someone at Apple who works on Archive Utility and discovered this was a known issue and it got addressed in the release for 10.8.x.
Now if everyone here is affected by the same issue I was, it should be fixed in 10.8.x+. If anyone else is still affected by it and on 10.8.x or 10.9.x, then there's at least two issues here.