Bug when using the java.util.zip classes to write zip files

Introduction

I was writing a little .NET app in C# and was looking for a small library that would let me read and write zip files. That's when my first Google search gave me a link to Using the Zip Classes in the J# Class Libraries to Compress Files and Data with C#. Great! - that was my first reaction, but it didn't last too long. You can read zip files alright, but when you write zip files, if you have binary files (as you most often will), the generated zip file will be corrupt and you can't read it back. Funnily, WinZip does open it (ignoring the header errors) and the suggested solution by a Microsoftie in the one of the MS NGs was to extract all files using WinZip and then to zip it back. LOL. Why'd anyone want to use the zipping libraries at all if they had the option of bringing WinZip into the picture?

There is not even a KB article on this bug - bad! I lost about half a day when I was using these classes because I initially thought it was something wrong in my code. Anyway, this is a warning to everyone. Do not use the J# class libraries for zipping/unzipping if you are using the BCL 1.1 version. Heath Stewart (C# MVP and CodeProject Editor) has informed me that the BCL 2.0 includes zipping functionality - so that's really good news. And until that comes out, a very good free alternative to the J# classes is SharpZipLib which I very strongly recommend.

Bug demo

1. Create a new C# console app project
2. Add a reference to vjslib (...Microsoft.NET\Framework\v1.1.4322\vjslib.dll)
3. Copy/paste the following code into your main cs file :-

   using System;
   using System.IO;
   using java.util.zip;
   
   class MainClass
   {
     [STAThread]
     static void Main(string[] args)
     {
       BugDemo();
     }
   
     static void BugDemo()
     {
       //Write zip file
       ZipOutputStream os = new ZipOutputStream(
         new java.io.FileOutputStream("test.zip"));
       ZipEntry ze = new ZipEntry("gluk.gif");
       ze.setMethod(ZipEntry.DEFLATED);
       os.putNextEntry(ze);
       java.io.FileInputStream fs = 
         new java.io.FileInputStream("gluk.gif");
       sbyte[] buff = new sbyte[1024];
       int n = 0;
   
       while ((n=fs.read(buff,0,buff.Length))>0)
       {
         os.write(buff,0,n);
       }
       fs.close();
       os.closeEntry();      
       os.close();
   
       Console.WriteLine("Okay, the zip has been written.");
   
       //Read zip file
       try
       {
         //Bug will occur here
         ZipFile zf = new ZipFile("test.zip");  
       }
       catch
       {
         Console.WriteLine("Bug confirmed!");
       }
     }
   }

4. Now make sure you have a gluk.gif in the same folder as the executable.

5. Compile and run.

Workaround

There is no real workaround to the problem. You can use the alternative library I mentioned above or wait for Whidbey.