From:	"Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Organization:	Darmstadt University of Technology
To:	eliz AT is DOT elta DOT co DOT il
Date:	Fri, 7 Jul 2000 16:07:04 +0200
MIME-Version:	1.0
Subject:	Re: A remark about unzip32
CC:	djgpp AT delorie DOT com
X-mailer:	Pegasus Mail for Windows (v2.54DE)
Message-ID:	<8CE12EE1F93@HRZ1.hrz.tu-darmstadt.de>
Reply-To:	djgpp AT delorie DOT com

Date: Fri, 07 Jul 2000 11:37:31 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
> I know about this problem with InfoZip's programs for quite some time
> (discovered it with Textutils, as you did).  My version of UnZip is
> very old, and since no one until now complained about the Textutils
> test suite, I was hoping that this is fixed in later versions.
> Evidently, it isn't.

Meanwhile I had the chance to download the latest version of unzip (version 5.41)
and the bug is still there.

> > I had the sources of unzip532 available so I can
> > send a patch that shows were the difficulty is located.
> > The "bug" is in function map2fat in file unz532/msdos/msdos.c.
> > 1) I know that this is not the appropiate place to send this
> > patch but the intention is to call your attention to this difficulty.
> > 2) This patch shall only show where the bug is and not
> > fix it. The patch simply defines out the faulty part of the
> > function. This is probably a too crude approach.
>
> I think unzip in its DJGPP version should simply reuse the code from
> DJTAR.  (With minor changes, the same code is in the DJGPP ports of
> GNU Tar and cpio.)  Or just truncate the name to 8+3 and forget all
> the other trickery.  In any case, I suggest to send diffs to the UnZip
> maintainers.

I will try to fix this as soon as possible and send patches to the maintainers.

- Raw text -