Date:	Tue, 02 Sep 1997 10:44:08 +1100
From:	Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject:	Re: Rebuilding gcc - "c-parse.gperf" not found
In-reply-to:	<340a3b80.10574464@snews.zippo.com>
To:	pjfarley AT dorsai DOT org (Peter J. Farley III), djgpp AT delorie DOT com
Message-id:	<199709012249.KAA25368@teleng1.tait.co.nz gatekeeper.tait.co.nz>
Organization:	Tait Electronics Limited
MIME-version:	1.0
Comments:	Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>

On  1 Sep 97 at 4:04, Peter J. Farley III wrote:

> Wow!  Now *that* is nice news to hear!  Many thanks, friend.
> 
> Let me repeat your statements, so I see if I understand them
> correctly.  Placing this entry in the registry under Win95 will
> disable the creation of *initial* numeric suffixes (as with the
> creation of a "longname" file that is the first of it's 8.3 flavor),
> and files subsequent to the first of a given 8.3 name *will* result
> in creation of 8.3 names with numeric suffixes (like ~1, ~2, etc.).

Yes, this is correct. Hoever, be carefull with it, as there is one 
gotcha (trap): if you have a file called `Makefile.in.in' (goes to 
`MAKEFILE.IN') and you try to delete `Makefile.in', `Makefile.in.in' 
will be deleted.  This happend to me when I tried to build gnu tar on 
my system. The configure script tried to build `Makefile.in' from 
`Makefile.in.in' but first would delete `Makefile.in', but because 
`Makefile.in' did not initially exist, `Makefile.in.in' had the short 
name `MAKEFILE.IN'.

To me, this is an issue of bad design in the handling of long file 
names.  I feel that when using the lfn calls, the shor file name 
should only ever be matched if there is no long file name for that 
file.  Sigh, not to be I guess, and I suppose that's why numeric 
tails are on by default (had to turn them back on to build gnu tar).

Just a warning. It doesn't happen often.
Bill
--
Leave others their otherness.

- Raw text -