Menu
▾
▴
jazzlib-developers — Creating a pure-Java port of the zlib compression library of functions.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(6) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
(2) |
| 2003 |
Jan
(1) |
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
| 2004 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(5) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2005 |
Jan
(3) |
Feb
(8) |
Mar
(5) |
Apr
|
May
(4) |
Jun
(4) |
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Martin W. <mar...@xm...> - 2001-12-03 21:56:42
|
Hi I figured it out by looking at the spec (http://www.pkware.com/support/appnote.html). According to that document a zip file consists of: [local file header1] [file data 1] [data_descriptor 1] [...] The [data_descriptor] is what I referred to as extended local header. The [local file header1] contains a "general porpose bit flag" which, if set accordingly, signals that the [data descriptor] header is there. "This descriptor exists only if bit 3 of the general purpose bit flag is set. [...] This descriptor is used only when it was not possible to seek in the output zip file, e.g., when the output zip file was standard output or a non seekable device." So I guess this was expected behavior after all since we have to use ZipOutputStream to create a zip file in Java. Btw, I solved it by creating the file twice. First time just to fetch the zip-information into a ZipEntry and then use that ZipEntry to recreate the file again. It's a mess, but my customer uses some www.dynazip.com lib which cant handle it afaik. :-) Thanks anyway. je...@pi... wrote: > I'm forwarding the message below to the list > ------------------------------------------------------------------------ > > Hello > > I hope you have the time to just take a look at this and maybe give me a > comment or hint > > I am using jazzlib0.03 to create a zip-file containing one file. The > zip-file is then used by ziplib from PKWare. > > The created file are correct is that sense that all my zip-aware > programs (zip, unzip, pkzip, winzip) > > Unfortunately the lib which is supposed to use my zipped file cannot > open the file for some reason. When I compare the output from my zipinfo > program (unzip -Z -v myfile.zip) and the same files zipped with Winzip, > I get something like this: > > diff myfile.zip winzipped_file.zip > 1c1 > < Archive: myfile.zip 203 bytes 1 file > --- > >>Archive: winzipped_file.zip 187 bytes 1 file >> > 6,7c6,7 > < Actual offset of end-of-central-dir record: 181 (000000B5h) > < Expected offset of end-of-central-dir record: 181 (000000B5h) > --- > >> Actual offset of end-of-central-dir record: 165 (000000A5h) >> Expected offset of end-of-central-dir record: 165 (000000A5h) >> > 13c13 > < beginning of the zipfile is 124 (0000007Ch). > --- > >> beginning of the zipfile is 108 (0000006Ch). >> > 30c30 > < extended local header: yes > --- > >> extended local header: no >> > 39,41c39,41 > < apparent file type: binary > < non-MSDOS external file attributes: 000000 hex > < MS-DOS file attributes (00 hex): none > --- > >> apparent file type: text >> non-MSDOS external file attributes: 81B600 hex >> MS-DOS file attributes (20 hex): arc >> > > > Apparently there is a "extended local header" in files created by > jazzlib which does not exist in files created using "other zippers". I > have tried to figure out what an ELH means, but zero result so far. I > checked jazzlib sources, but that didn't help me. > > Also there is some diff regarding file types and file attributes, but I > hardly think they are the problem. > > If you have any ideas what this is, and how I can force jazzlib not to > create that ELH I would be very grateful! > > Btw, I tried using standard java.util.zip package and that gives the > same result as jazzlib -- Martin Wickman, X Media Solutions | mailto:mar...@xm... Box 3294, Holmbrogränd 1, S-600 03 Norrköping | http://www.xms.se Tel: +46 (0)11 24 48 49 | Fax: +46 (0)11 24 48 09 |
|
From: <je...@pi...> - 2001-12-03 21:25:04
|
Hello Martin After reading through your message my first suggestion is that you try another library to read your zip files. I didn't implement the code that deals with the .zip file structure, I might look at this later when I have some time. John Leuner --------------------------------------------- This message was sent using M-Web Airmail. http://airmail.mweb.co.za/ |
|
From: <je...@pi...> - 2001-12-03 21:13:18
|
I'm forwarding the message below to the list ------------------------------------------------------------------------ Hello I hope you have the time to just take a look at this and maybe give me a comment or hint I am using jazzlib0.03 to create a zip-file containing one file. The zip-file is then used by ziplib from PKWare. The created file are correct is that sense that all my zip-aware programs (zip, unzip, pkzip, winzip) Unfortunately the lib which is supposed to use my zipped file cannot open the file for some reason. When I compare the output from my zipinfo program (unzip -Z -v myfile.zip) and the same files zipped with Winzip, I get something like this: diff myfile.zip winzipped_file.zip 1c1 < Archive: myfile.zip 203 bytes 1 file --- > Archive: winzipped_file.zip 187 bytes 1 file 6,7c6,7 < Actual offset of end-of-central-dir record: 181 (000000B5h) < Expected offset of end-of-central-dir record: 181 (000000B5h) --- > Actual offset of end-of-central-dir record: 165 (000000A5h) > Expected offset of end-of-central-dir record: 165 (000000A5h) 13c13 < beginning of the zipfile is 124 (0000007Ch). --- > beginning of the zipfile is 108 (0000006Ch). 30c30 < extended local header: yes --- > extended local header: no 39,41c39,41 < apparent file type: binary < non-MSDOS external file attributes: 000000 hex < MS-DOS file attributes (00 hex): none --- > apparent file type: text > non-MSDOS external file attributes: 81B600 hex > MS-DOS file attributes (20 hex): arc Apparently there is a "extended local header" in files created by jazzlib which does not exist in files created using "other zippers". I have tried to figure out what an ELH means, but zero result so far. I checked jazzlib sources, but that didn't help me. Also there is some diff regarding file types and file attributes, but I hardly think they are the problem. If you have any ideas what this is, and how I can force jazzlib not to create that ELH I would be very grateful! Btw, I tried using standard java.util.zip package and that gives the same result as jazzlib /Kind regards Martin Wickman --------------------------------------------- This message was sent using M-Web Airmail. http://airmail.mweb.co.za/ |
|
From: Jochen H. <Joc...@In...> - 2001-10-22 17:23:35
|
On Oct 20, John Leuner wrote: > > BTW, we should make a script that copies the classpath java.util.zip > > sources into a net.sf.jazzlib package which can then be used for > > inclusion in applet code. This package could be distributed from the > > SourceForge site. John what do you think? > > I have updated the sf site with release 0.03. > > I have not tested it, but it should work. > > Where should I put the script? > > Should I put it in the java.util.zip directory in Classpath (that's > where I run it from, do you think they'll mind if there's a script > there in CVS?). There is also a classpath/script directory. And the mkcollections.pl.in script (that does a very similar thing) was placed in classpath/lib. Jochen |
|
From: John L. <je...@pi...> - 2001-10-20 21:07:34
|
> BTW, we should make a script that copies the classpath java.util.zip > sources into a net.sf.jazzlib package which can then be used for > inclusion in applet code. This package could be distributed from the > SourceForge site. John what do you think? I have updated the sf site with release 0.03. I have not tested it, but it should work. Where should I put the script? Should I put it in the java.util.zip directory in Classpath (that's where I run it from, do you think they'll mind if there's a script there in CVS?). John Leuner |
|
From: John L. <je...@pi...> - 2001-10-20 19:33:32
|
> That bug was already fixed in the classpath repository. There was > another bug that could cause a ArrayIndexOutOfBoundException, which > was fixed there, too. > > BTW, we should make a script that copies the classpath java.util.zip > sources into a net.sf.jazzlib package which can then be used for > inclusion in applet code. This package could be distributed from the > SourceForge site. John what do you think? Sounds like a good idea. I'll take responsibility for this (unless you want to do it). This means changing all the headers in the source files to indicate a new package. I noticed today that the jikes research VM people (used to be called Jalapeno) have used Jazzlib (at one time or another). http://www-124.ibm.com/developerworks/oss/jikesrvm/index.shtml I'll start working on the new package, I'll post to the list and update the web site when I'm done. John Leuner |
|
From: Jochen H. <Joc...@In...> - 2001-10-18 09:18:31
|
On Oct 9, Jörg Prante wrote: > Hi! > OK it's me again. Please apologize but my fix for ZipFile.java was not > correct! > > It fails with the trivial case, an empty zip file. Empty zip files are rare > and useless, of course, but an EOFException in that case is really not > required at all. Attached you find a correct ZipFIle.java that works now. I have committed a similar fix to the classpath repository. Note that this now contains the official code. > Another issue was that DeflaterEngine does not correctly deflate multiple zip > entries. It fails at a subsequent zip entry to deflate with an > ArrayIndexOutOfBoundException. I guess this has been reported as a bug. I > fixed this, too. You find a modified DeflaterEngine.java attached. The > reset() method has been extended by two more lines to reset some fields. That bug was already fixed in the classpath repository. There was another bug that could cause a ArrayIndexOutOfBoundException, which was fixed there, too. BTW, we should make a script that copies the classpath java.util.zip sources into a net.sf.jazzlib package which can then be used for inclusion in applet code. This package could be distributed from the SourceForge site. John what do you think? Jochen |
|
From: <joe...@gm...> - 2001-10-09 17:17:24
|
Hi! OK it's me again. Please apologize but my fix for ZipFile.java was not correct! It fails with the trivial case, an empty zip file. Empty zip files are rare and useless, of course, but an EOFException in that case is really not required at all. Attached you find a correct ZipFIle.java that works now. Another issue was that DeflaterEngine does not correctly deflate multiple zip entries. It fails at a subsequent zip entry to deflate with an ArrayIndexOutOfBoundException. I guess this has been reported as a bug. I fixed this, too. You find a modified DeflaterEngine.java attached. The reset() method has been extended by two more lines to reset some fields. With jazzlib status now, I can now add and remove zip entries within an archive from a Swing tool. That's cool! Once again thanks for the library. If there are more jazzlib issues, I'll be back. Cheers, Jörg |
|
From: John L. <je...@pi...> - 2001-10-08 17:51:51
|
> Hello, > > you have done a good job, I use jazzlib as a replacement for java.util.zip > (which does not work) for a Swing-based Zip tool. > > First let me allow the hint that Sun does not permit the usage of "java.util" > packages for third parties. Maybe you get into trouble. These classes are now part of the Classpath project (http://www.gnu.org/software/classpath/). The Classpath project is a replacement for Sun's class libraries, so java.util.zip is the correct place for these classes. > Now my contribution. There is a bug in your java.util.ZipFile. > > According to > > www.pkware.com/support/appnote.html > > there can be variable-length comments at the end of the file. Your code > assumes the central directory size is fixed, but it's not. Some "odd" Zips > will fail with a ZipException "Missing end of central directory". > > Attached you find a util.ZipFile source file for your convenience. It fixes > this bug by seeking backward from end of file minus minimum size of the > central directory. All Zips I have are recognized now. > > My fix throws a "invalid zip or broken" if it fails to find the header > signature. Your contribution would be more useful if you downloaded the latest version of ZipFile (from http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipFile.java?rev=1.3&content-type=text/vnd.viewcvs-markup ) And gave us a diff which showed the changes. Do you have an example of a zip file that has a comment at the end? Thanks John Leuner |
|
From: <joe...@gm...> - 2001-10-08 14:05:30
|
Hello,
you have done a good job, I use jazzlib as a replacement for java.util.zip
(which does not work) for a Swing-based Zip tool.
First let me allow the hint that Sun does not permit the usage of "java.util"
packages for third parties. Maybe you get into trouble.
Now my contribution. There is a bug in your java.util.ZipFile.
According to
www.pkware.com/support/appnote.html
there can be variable-length comments at the end of the file. Your code
assumes the central directory size is fixed, but it's not. Some "odd" Zips
will fail with a ZipException "Missing end of central directory".
Attached you find a util.ZipFile source file for your convenience. It fixes
this bug by seeking backward from end of file minus minimum size of the
central directory. All Zips I have are recognized now.
My fix throws a "invalid zip or broken" if it fails to find the header
signature.
Cheers and continue your good work
Jörg |
6 messages has been excluded from this view by a project administrator.
