Date:	Fri, 11 May 2001 20:06:23 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	jeffw AT darwin DOT sfbr DOT org
Message-Id:	<7048-Fri11May2001200622+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<20010511105129.A1794@kendall.sfbr.org> (message from JT Williams
	on Fri, 11 May 2001 10:51:29 -0500)
Subject:	Re: DJGPP 2.04 release date
References:	<20010508142430 DOT N23521 AT kendall DOT sfbr DOT org> <Pine DOT SUN DOT 3 DOT 91 DOT 1010509132856 DOT 19857O-100000 AT is> <20010509093658 DOT C27959 AT kendall DOT sfbr DOT org> <9743-Wed09May2001190506+0300-eliz AT is DOT elta DOT co DOT il> <20010511105129 DOT A1794 AT kendall DOT sfbr DOT org>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Fri, 11 May 2001 10:51:29 -0500
> From: JT Williams <jeffw AT darwin DOT sfbr DOT org>
> 
> -: Otherwise, IMHO we simply retrack the bad design decisions
> -: made by Microsoft.  They at least have the excuse that they were
> -: trying to solve a problem no one ever thought about.
> 
> Do you consider appropriating unused directory entries to hold the LFN
> entry as one of those decisions?

No, this is not what bothers me in Microsoft's design.  The additional
directory entries are ugly but effective, and their negative side
effects are minimal.  So they are invisible as far as users are
concerned.

What is _not_ so invisible are the nuisance with the numeric tails,
the fact that rewriting a file with legacy DOS calls wipes out the
long name, the stupid decision to return DOS names in UPPER case, the
bugs with renaming files we saw over the years, etc.

> Indeed, it seems that any DJGPP+DOS-specific LFN utility would be free
> to define its own `standards', provided the LFN API reports the right
> information.  Just thinking out loud, now, I'm wondering about some sort
> scheme for FAT<-->inode mapping....

Sorry, you lost me with the last sentence.  How is that relevant to
the issue we were discussing?

- Raw text -