Mail Archives: djgpp-workers/2001/05/09/11:03:11
-: > 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.
- Raw text -