Compress with ZLibStream does not deflate with zlib library

Jul 29, 2010 at 3:21 PM
Edited Jul 30, 2010 at 6:47 AM

I have old code that uses zlib library from and I am trying out this DotNetZip library to use in my new code.

I can deflate the data from the zlib code with DotNetZip, but the zlib code cannot deflate the last block of buffer data from DotNetZip library, so I get invalid data.

I have gone through the code for both libraries and I can see they are mostly the same and I just can't figure out what is causing the problem. This is what happens, the last 4 bytes in the result file are not the same and everything else is same.

I am sending buffer of size 3462929, and in the last loop the value in _codec.Adler32 = 3654184877, which converts to the last 4 bytes = D9 CE 6F AD.

Same buffer goes via the code and the value in adler = 2943381421, which converts the last 4 bytes = AF 70 6F AD.

It's always the first 2 of the 4 last bytes that are different, if you get what I mean.

This is the code block I am using and its same for both libraries, I just switch the using statement and the ZlibStream object between test

FileStream outFileStream = new FileStream(outfile, FileMode.Create); 
ZLibStream outZStream = new ZLibStream(outFileStream, CompressionMode.Compress); 
FileStream inFileStream = new FileStream(infile, FileMode.Open);

int flen = (int)inFileStream.Length; 
byte[] buffer = new byte[flen + 1]; 
int len; 

while ((len = inFileStream.Read(buffer, 0, flen)) > 0) 
  outZStream.Write(buffer, 0, len); 

Edit:  I found out that if I compress small 3k xml file, both zip files are same, but if I try 3.4Mb binary data file, 
then the mixup in those 2 bytes happens.  I am using the DotNetZip lib and lib as is from both websides,
just include them into the project and then run this code above 2 with different Stream objects.
Oct 4, 2010 at 8:58 AM


i have the same problem with managed zlib. The Adler32 from DotNetZip is different from that calulate in managed zlib.

Also the Java inflater report incorrect data format when uncompressing the DotNetZip file but not the managed zlib file.

So I assume that there is a bug in Dotnetzip's adler32 calculation.


Any Idea's ?

Thank's Stefan

Oct 4, 2010 at 9:32 AM

I think the problem is an overflow issue in Adler32 if you specify a large buffer size. There's an int value in the code which can sometimes overflow depending on buffer size and data values and ends up giving the wrong Adler32 crc.

You can try to reduce the size of "flen" in your program which will then sidestep the issue - anything less than 3980 bytes should avoid the problem. I also proposed a couple of different fixes to the Adler32 class in this thread



Oct 4, 2010 at 10:47 AM

Hi Mike

I tried out your code differences on my Library code and it solved the problem, now both compressed files compare same from both libraries.

Thanks a lot


Oct 4, 2010 at 2:00 PM
Thanks again, Mike. For the past several months I have not had a pc that works, nothing I could use to build and test DotNetZip. I'm hoping to rectify that and incorporate your fixes soon. Glad to see you all helping each other out.
Oct 4, 2010 at 2:11 PM

No problem. Happy to help.