[Kaffe] another ZipOutputStream patch

[Moses DeJong]

On Tue, 16 Feb 1999, Archie Cobbs wrote:

> Moses DeJong writes:
> > @@ -210,6 +207,7 @@
> >                         throw new ZipException("crc not set in stored entry");
> >                 }
> >         }
> > +       ze.flag = ze.method;
> >  
> >         if (curr == null || curr.method != ze.method) {
> >                 if (ze.method == STORED) {
> 
> ..
> 
> > +       put32(lh, LOC_SIGNATURE, (int)LOC_HEADSIG);
> > +       put16(lh, LOC_VERSIONEXTRACT, ZIPVER);
> > +       put16(lh, LOC_FLAGS, ze.flag);
> >  
> >         put16(lh, LOC_METHOD, ze.method);
> >         put16(lh, LOC_TIME, 0);
> 
> Are you sure this is correct? I.e., it's not just that the JDK
> is setting the flag to a value that happens to equal the value
> of ze.method? Do you have conclusive documentation and/or code
> that this is based on?
> 
> Just double checking...
> 
> Thanks,
> -Archie

There really is nothing in the docs about this. I am just using
a couple of programs to dump an example stream and then compare
the stream (the Zip file) that is generated by Kaffe and the JDK.
I have no idea why Sun is doing this but with this change the
part of the stream generated by Kaffe matches that of the JDK.
I could provide you with the files I am using the write and
compare generated the zip files if you want to test them yourself.
To be honest, I am really working in the dark here. Jar files
generated by my jar program work perfectly under the JDK but
they do not work under Kaffe, so I am aiming to "fix" the
problem but getting Kaffe to produce the exact same binary
data in it's Zip output. My testing showed that Kaffe always
produced a (byte) 0 for this data while the JDK would produce
(byte) 8 if the stream was compressed and (byte) 0 if it was not
compressed. The value of ZipConstants.DEFLATED is also (byte) 8
so it seemed like a natural conclusion. 

Mo DeJong
dejong at cs.umn.edu