On 23/11/2009, Jesse Wilson <[email protected]> wrote: > On Mon, Nov 23, 2009 at 8:40 AM, Jesse Wilson <[email protected]>wrote: > > > Rolled back as r883400. I'll investigate the Pack200 test problems and push > > this back in after code freeze. > > > > FYI: The root problem is a bug in our ZIP decoding. It fails to cope with > Z_SYNC_FLUSH blocks and crashes. I've submitted a failing testcase that > demonstrates the problem: > http://svn.apache.org/viewvc?view=revision&revision=883478 > This test case passes on the RI.
FYI: I can open the jar using the RI jar application on WinXP, but Winzip 9.0 complains. On people.apache.org the jar tool works but UnZip 6.00 reports: 6 extra bytes at beginning or within zipfile (attempting to process anyway) AFAICT, Ant 1.7.1/Java 1.4.2 does not work either on Win/XP - no error reported, but no output either. So Harmony is not alone in having problems with the test jar. > There's an unfortunate consequence of adding flush() support to > deflate/zip/gzip; one I probably should have forseen before checkin. When a > Deflater/Zip/GzipOutputStream is wrapped by a FilterOutputStream (such as > BufferedOutputStream), the compressed datastream will be *different* if we > support flush; even if the user doesn't call flush() directly. Here's why... > BufferedOutputStream.close() always calls this.flush(), which in turn > calls delegate.flush(), > DeflaterOutputStream.flush() emits a Z_SYNC_FLUSH block if we support > flushing. If we don't support flushing, that block isn't emitted. > As far as I'm concerned, supporting flush is the right thing to do. It's > essential for any kind of compressed interactive network channel, such as > XEP-0138 <http://xmpp.org/extensions/xep-0138.html> for compressed instant > messaging streams. > > I'll investigate fixing the Jar bug... >
