From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Patch BUG??
Date: Sat, 9 May 1998 22:36:35 +0100
Organization: None
Message-ID: <GLf7iAAjxMV1Ewk5@talula.demon.co.uk>
References: <19980509172947 DOT AAG16984 AT ppp105 DOT cartsys DOT com>
 <3554ADE1 DOT 5E18 AT cam DOT org>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
Lines: 32
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Vic writes:
>DJGPP is in e:\djgpp
>Allegro is in e:\djgpp\allegro
>I unpak the diff file in e:\djgpp
>I call patch with patch -p1 < difapr26.diff

Odd. I just tested this sequence of events, which is essentially the
same as what you are doing, and it worked flawlessly for me:

   md tmp
   cd tmp
   unzip \backup\alleg30.zip
   (a copy of Allegro 3.0 is now in tmp/allegro/)
   unzip \backup\allegwip\difapr26.zip
   (prompts whether to overwrite keyboard.dat, I say yes)
   patch -p1 < difapr26.diff

This is using GNU patch 2.4.

>What is bothering me, and why I called it a bug (somewhere) is the fact
>that the SAME thing (in the SAME conditions) works fine IF LFN=N. If
>LFN=Y, without changing anything else, the patch fails

Did you by any chance unzip alleg30.zip with a non-LFN archiving
program? If so, it will have truncated some filenames like "ChangeLog",
so they can't be found by the patch utility. If you want to use LFN's,
it is essential to have an unzipper that supports them...


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
"Miracles are nothing if you've got the wrong intentions" - Mike Keneally