Date: Wed, 09 May 2001 19:05:07 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: jeffw AT darwin DOT sfbr DOT org Message-Id: <9743-Wed09May2001190506+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: <20010509093658.C27959@kendall.sfbr.org> (message from JT Williams on Wed, 9 May 2001 09:36:58 -0500) Subject: Re: DJGPP 2.04 release date References: <20010508142430 DOT N23521 AT kendall DOT sfbr DOT org> <20010509093658 DOT C27959 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 Precedence: bulk > Date: Wed, 9 May 2001 09:36:58 -0500 > From: JT Williams > > -: > 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. I wasn't talking about the numeric tails; they indeed could go away (good riddance!). I was talking about the truncated names created by Windows 9X when NameNumericTails is set to zero. That is, emulate what DOS is doing when you pass it a long file name. > -: 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?' No, there are real problems. First, any system where you install DJGPP packages under the LFN TSR becomes unusable without the LFN TSR (or if you set LFN=n) -- most DJGPP packages will cease working, because many of them come with at least one file with a long name, like foo.info. I understand that after unloading the LFN TSR, you will see anything but foo.inf instead. Second, you lose the possibility to invoke non-DJGPP programs, which cannot benefit from the LFN API: if the parent DJGPP program invokes them with a long file name as an argument, those non-DJGPP programs will not find those files. This includes COMMAND.COM and all its internal commands. There's also a particular function of the LFN API that is supposed to give the filesystem a hint about the numeric tail; I guess it becomes a no-op in Bill's implementation. But that's a relatively minor problem. I'm sure there will be other problems as well, I just didn't have enough time to think about them ;-) > 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. 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 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.