Mail Archives: djgpp-workers/2001/05/09/12:55:37
> Date: Wed, 9 May 2001 09:36:58 -0500
> From: JT Williams <jeffw AT darwin DOT sfbr DOT org>
>
> -: > 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.
- Raw text -