Date:	Wed, 10 Dec 1997 11:33:04 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Esa DOT Peuha AT Helsinki DOT FI
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Patches for djtar
In-Reply-To:	<Pine.OSF.3.96.971210095426.3345A-100000@vesuri.Helsinki.FI>
Message-ID:	<Pine.SUN.3.91.971210112748.10111I-100000@is>
MIME-Version:	1.0

On Wed, 10 Dec 1997, Esa A E Peuha wrote:

> > Note that the seemingly large change in the `get_new_name' function is
> > just a reindentation, since the code indentation was left intact after
> > it was copied from an inner block, which made the program structure
> > hard to read.
> 
> So the -b switch to diff was a bad idea...

You should *NEVER* use -b when submitting patches, because they confuse 
`patch'.  I had some very uneasy correspondence with DJ when he couldn't 
apply my patches, until I figured out that -b was the culprit.

> 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?

> I think that's a false analogy. Previously, every file had to be untarred
> after decompressing, so there was no point to ask what to do with the
> file, but now a zipped .tar file can be reasonably considered either as a
> .zip file or a compressed .tar file, so the user might want to choose the
> format.

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?

- Raw text -