[Jazzlib-developers] Re: Extended Local Header

[Martin W. <mar...@xm...>]

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