Date: Wed, 10 Dec 1997 12:48:36 +0200 (EET)
From: Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>
Reply-To: Esa DOT Peuha AT Helsinki DOT FI
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Patches for djtar
In-Reply-To: <Pine.SUN.3.91.971210112748.10111I-100000@is>
Message-ID: <Pine.OSF.3.96.971210123534.18937A-100000@vesuri.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk

On Wed, 10 Dec 1997, Eli Zaretskii wrote:

> On Wed, 10 Dec 1997, Esa A E Peuha wrote:
> 
> > This is not trivial. The main function must read four bytes from the
> > beginning of the file, but those four bytes must also be available to the
> > untar/unzip code. The input file might not be seekable (if it is raw
> > disk), and it might not be possible to open the file, read the bytes and
> > close it to be opened again (if it is stdin). But if anyone can think of a
> > solution, then please implement this.
> 
> How about an old and ugly hack of keeping the first two bytes in a global 
> variable?

Maybe a less ugly hack would be to change oread.c so that the main
function can read the first four (not two) bytes with a special function,
and they would still be available with the normal oread function.

> I was talking about the automatic detection of the compression method.  
> As far as I could see that's the only thing that .zip extension is 
> checked for.  Did I miss something?

No, that's correct. But if a zipped file doesn't have that extension,
it's treated like in the previous version of djtar, ie. fed to the untar
code. I meant that the user might well want this, to avoid having to call
djtar twice.

Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/