From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>, <jeffw AT darwin DOT sfbr DOT org>
Cc: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Subject: Re: DJGPP 2.04 release date
Date: Thu, 10 May 2001 19:06:35 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIKECNCDAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <9743-Wed09May2001190506+0300-eliz@is.elta.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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
Precedence: bulk

[Resending this; the AAA below used to use X's, which were dutifully
blocked by DJ's antispam device]

> What is needed is an algorithm that will produce properly truncated
> 8+3 names from an arbitrary long name.  I once posted a description of
> what Windows 9X does' I can post that again, if it's needed.  To be
> useful, the LFN TSR should make such properly truncated SFNs, unless
> there's already an identical SFN (meaning that another file clashes
> with this one).  How such clashes are resolved is less important--for
> all I care, you could leave the CRC way of dealing with that--but the

I for one would prefer a slightly more readable version; for example,
Win4Lin's dos emulation (in which cwsdpmi doesn't run, so no DJGPP)
uses a AAA'YYYY.ZZZ (or AAAA'YYY.ZZZ, I forget) scheme for files on Linux
partitions (Win9x LFN's look like they do on regular DOS), where AAA is
the first portion of the filename, zzz is the first part of the extension
(if any), and YYYY is some sort of hash of the full filename. Obviously,
this has a greater chance of collisions if there are many similar file
names, but it does leave the SFN slightly more intelligible.

> default truncation should definitely be there, and it should be on by
> default.  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.
I agree.  Then again, I hardly ever use plain DOS these days, so my
vote doesn't really count for much.