From: "Juan Manuel Guerrero" 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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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" > 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.