Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3EB22335.A1182821@phekda.freeserve.co.uk>
Date:	Fri, 02 May 2003 08:50:13 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: djtar and slightly weirdly formatted ZIPs [PATCH]
References:	<E199Nch-0000l9-00 AT phekda DOT freeserve DOT co DOT uk> <Pine DOT OSF DOT 4 DOT 51 DOT 0304301442320 DOT 5104 AT sirppi DOT helsinki DOT fi>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Esa A E Peuha wrote:
> 
> On Sat, 26 Apr 2003, Richard Dawe wrote:
> 
> > I noticed the other day that djtar cannot extract the flex 2.54 binary
> > package from Simtel.NET - v2gnu/flx254b.zip. This is because
> > it has a slightly weird header. Before the normal ZIP local header
> > it has the header "PK00". I can't find out what this is for.
> 
> http://www.pkware.com/products/enterprise/white_papers/appnote.txt says
> that is the temporary spanning marker signature (which means that it's
> a normal zip file made by a program that can make slipt zips).

Thanks for the reference.

> > Something else I noticed is that the output for djtar -t is not consistent
> > between ZIP and tar'd formats. For ZIPs it just lists the filenames.
> > For tar files it lists attributes, dates and file sizes too.
> 
> That's probably because I wrote epunzip.c as an exercise of least
> effort. :-)  Dates and sizes are easy to add, but attributes may depend
> on the system with which the zip file was created (see the specification
> above), so currently there's no attribute support at all.  Of course the
> easy cases (MS-DOS and Unix) could (and should) be supported, if you are
> willing to write the code.

I was wondering what the "ep" in epunzip stood for. ;)

I don't have much time right now for DJGPP. It seems unlikely that I will have
much time for the next month and a half - new job, moving house, etc.

> > OK to commit?
> 
> Looks fine to me.

I could make the code ignore temporary spanning markers, but generate an error
when it sees other header types before the local header. At the moment it
could ignore headers that are important. Do we want it to be strict or behave
like Info-Zip's unzip?

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -