zip files created cannot be unzipped on Mac OS X (10.6) with default unarchiver (Error- 1 Operation not permitted) about mod_zip HOT 7 CLOSED

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.

from mod_zip.

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.

Mystery.

Anyway, would be great to get this fixed! (no idea what the problem is though)

from mod_zip.

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.

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

from mod_zip.

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.

from mod_zip.

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.

from mod_zip.

Closing the issue because Apple resolved this problem on their end in OS X 10.8.

Anyone affected on a newer version of OS X is welcome to open a new issue.

from mod_zip.