Re: regression in 0.8/0.9 and ZIP_GPBF_DATA_DESCRIPTOR

[Dieter Baron <dillo%danbala.tuwien.ac.at@localhost>]

On Sun, Mar 22, 2009 at 05:04:09PM +0100, Pierre Joye wrote:
> On Sun, Mar 22, 2009 at 12:52 PM, Pierre Joye 
> <pierre.php%gmail.com@localhost> wrote:
> > hi,
> >
> > It seems that the last versions of libzip introduced a regression with
> > one of the bug related to ZIP_GPBF_DATA_DESCRIPTOR (or why it was
> > introduced). A good reproduce are OpenOffice document, open a
> > document, modify it (content.xml for example) and save it. The
> > resulting archive can't be opened again with openoffice (2.0/3.0).
>
> It seems that the following code (current mercurial head code):
> 
>           if (de.bitflags & ZIP_GPBF_DATA_DESCRIPTOR) {
> 
>               de.crc = za->cdir->entry[i].crc;
>               de.comp_size = za->cdir->entry[i].comp_size;
>               de.uncomp_size = za->cdir->entry[i].uncomp_size;
>               de.bitflags &= ~ZIP_GPBF_DATA_DESCRIPTOR;
>           }
> 
> in zip_close.c:196 is gulty.
> 
> The data descriptor must be kept untouched or the archive cannot be
> read by oOO or some other reader (some flexible reader like textmaker
> viewer works, http://www.officeviewers.de/ as they do not care about
> the type of the zip archive).

  That is not true.  According to a simple test Thomas did, oOO can
read a zip archive where general purpose flag bit three is *not* set,
as created by unzipping the original archive and re-zipping it with
zip.

  Basically, that is what libzip is trying to do -- we do not stream
the output zip archive, therefore we do not need to use a data
descriptor or set general purpose flag bit 3.  It seems like libzip
messes this up somehow; I'll have a look.


> I think it is critical enough (many zip users use it to work with odt
> documents) to be solved. I wonder if it would make sense to fire a
> minor release for 0.9.0 so an update can be done easily.

  I'll see what I can do.

> About the current code in the hg repository, there are a couple of
> issues (integer types detections, portability on win like binary mode,
> crash under certain condition) that have been either reintroduced or
> never fixed.

  We are currently in the process of refining the API to make it more
portable (e.g. no more arguments of type size_t, ssize_t or off_t).
When it's settled, we will publish a snapshot for public testing, so
we can iron out these issues before the next release.

  Please also feel free to report any issues before then.

> Have you consider to use a bug tracker?

  Yes, but we haven't found one that suited our needs (integrates well
in our already slightly overloaded server environment, can be used via
web and email, can be integrated into our web site.)

> and to publish
> the commits via a mailing list?

  Yes, we can probably do that with minimal effort.  I think
redirecting replies to libzip-discuss and not archiving the source
changes mailing list would make most sense.  Do you agree?  (However,
be advised that the publically available hg copy is only updated every
6 hours, so you might have to wait a bit before acually accessing the
changes.)


                                        yours,
                                        dillo