Jun 1, 2010 at 5:37 PM
Edited Jun 1, 2010 at 5:57 PM


Jun 1, 2010 at 6:05 PM

Hi Rob,

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.

You can read more about this in the documentation for zip.EmitTimesInWindowsFormat .


Jun 1, 2010 at 6:06 PM
Edited Jun 1, 2010 at 6:07 PM

you removed the question!  what happened?

Jun 1, 2010 at 6:24 PM
Thanks Cheeso for the quick response!

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.

Thanks again,

On Jun 1, 2010, at 11:06 AM, Cheeso wrote:

From: Cheeso

what happened?

Read the full discussion online.

To add a post to this discussion, reply to this email (DotNetZip@discussions.codeplex.com)

To start a new discussion for this project, email DotNetZip@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

Jun 1, 2010 at 6:40 PM

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.