(removed)

The most common source of compatibility issues with zip files is related to timestamps.

The Zip specification allows several different ways to specify a timestamp on an entry. The default way is via an MS-DOS (yes!, Zip is an old spec) format, with resolution to 2 seconds. There's also a way to specify the "NTFS-format"
timestamp, with resolution to 100ns. And finally, several ways to store the timestamp in the zipfile in "unix" format, to a resolution of 1 second, if I recall correctly. I use these terms in quotes because there is nothing about any
of the formats that would prevent an application from reading or generating that format, on any platform. DotNetZip can read or generate zipfiles with timestamps in any of those formats. By default, DotNetZip emits timestamps in DOS and NTFS formats.

In the case of the Unix or NTFS "formats", the time data are stored in what is called "extra" fields in the zip entry metadata. According to the spec, Zip applications are supposed to ignore any "extra" field data they
don't understand. But I've found some applications don't ignore the extra data - they choke. Oddly, the main place I've seen this problem is on OS-X, when the zipfile contains entries with the NTFS-formatted timestamps. That seems to be the opposite
of what you're seeing.

If you want to test the theory that it is the timestamp causing the problem, set zip.EmitTimesInWindowsFormat to false., before adding any entries.

I finally made a test where I wrote the file out to the local server filesystem instead of using Response.TransmitFIle() and it opens just fine. So the corruption was happening in the response stream, not in the zip file.

Since your library is clearly awesome and not related to the problem, I removed the post (incidentally, I could not find an option to delete the post) other than to rename it as removed.

Ya - ok, that's the second common problem of incompatibility. It actually IS related to DotNetZip.

It's called "bit 3" in the zip file spec. It's a thing in the zip entry metadata that indicates that the zipfile has been produced by writing a write-only stream (like ASP.NET Response.OutputStream). And just as I described
with the timestamps, some archivers can handle a zipfile with bit 3 turned on, and some cannot.

Writing the file out to the filesystem avoids the bit 3 encoding, and avoids the problem.

Once again, it's OS-X that I've seen have this problem in the past, and not WinZip or Windows. So your results are a bit curious.

It's sometimes tricky to get the zipfile to be emitted without rubbish in the stream when writing directly to ASPNET Response.OutputStream. That could be the source of the problem, but it normally wouldn't result in different behavior on OSX vs Windows.

Anyway, I'm glad you sorted it out. Writing the zip to the filesystem and then using TransmitFile() would avoid either of those problems.