X-Authentication-Warning: kendall.sfbr.org: jeffw set sender to jeffw AT darwin DOT sfbr DOT org using -f
Date: Wed, 9 May 2001 09:36:58 -0500
From: JT Williams <jeffw AT darwin DOT sfbr DOT org>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: DJGPP 2.04 release date
Message-ID: <20010509093658.C27959@kendall.sfbr.org>
Mail-Followup-To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
	djgpp-workers AT delorie DOT com
References: <20010508142430 DOT N23521 AT kendall DOT sfbr DOT org> <Pine DOT SUN DOT 3 DOT 91 DOT 1010509132856 DOT 19857O-100000 AT is>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.SUN.3.91.1010509132856.19857O-100000@is>; from eliz@is.elta.co.il on Wed, May 09, 2001 at 01:29:18PM +0300
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

-: > It generates a 48-bit CRC for the LFN and uses that
-: > for the SFN---so instead of MICROS~1 you get a SFN that has characters
-: > from the upper 128 of the current character set.
-: 
-: I hope this is done only for the second long file name whose
-: truncation to 8+3 limits clashes with an existing file.  The first
-: occurence of a truncated file name should be left intact.

Nope, it's done unconditionally for all long file names.  Bill completely
discarded the MICROS~1 kludge.  If you unload the TSR, any LFNs you've
created will appear as SFNs using the upper 128 chars.  It was weird at
first, but I soon agreed with Bill that it was preferable to MICROS~1.

Bill included a feature to retain the original file extension (if present)
so that `long-file-name.tex' might appear as `********.tex', where `*' is
a char from the upper half of the code set.  I eventually disabled this
feature as a matter of personal preference.

I've also wondered about CRC collisions.  It is possible, but I've never
seen it happen;  evidently they are exceedingly rare for this application.

-: In other words, if none of the long names clash after truncation to
-: 8+3, their short names should not be munged in any way, they should be
-: simple truncations to 8+3.
-: 
-: If this is not so, I expect a lot of problems with this TSR.

Problems as in `that's not the way M$ does it?'  That may be the best
reason to use it ;-)  OTOH, it would be straightforward to replace the
CRC hash with a routine for generating ~-style names.  None of the
LFN interrupt service routines would change significantly.