From: spam@merlyn.demon.co.uk
JRS: In article , dated
Sat, 12 Mar 2005 12:44:27, seen in news:comp.lang.pascal.borland, Jason
Burgon posted :
>"Dr John Stockton" wrote in message
>news:NadfKpEs3iMCFwSS@merlyn.demon.co.uk...
>> JRS: In article , dated Fri, 11
>> Mar 2005 07:05:22, seen in news:comp.lang.pascal.borland, Jason Burgon
>> posted :
>> >"Dr John Stockton" wrote in message
>> >news:6itSE1Dt3LMCFwGH@merlyn.demon.co.uk...
>> >
>
>> >IIRC, if an 8.3, DOS compatible, all-uppercase, 7-bit ASCII-only
>> > filename is created by Win9x/ME (and possibly NTxx as well on
>> > FAT drives), then no LFN entries will be created for that file/folder.
>> > Because VFAT is case-preserving, this means that if the file/folder
>> > name contains any lowecase characters (or chars > #127, or...), then
>> > an LFN entry has to be generated.
>>
>> Just to clarify : you're saying that there's no problem with the case of
>> letters in floppies because [my understanding of] FV is wrong.
>
>FV?
Femme Verbeek.
>> But the SFN entry contains bytes, not characters; it is the
>> visual interpretation which is codepage dependent (so #$E5,
>> which I called sigma, could be seen as Otilde or nhacek or ???
>
>No, SFN entries contain 8-bit ~characters~, from the character set of the
>codepage (CP) that was active at the time the FAT entry was generated. It is
>not the visual representation that is CP-dependant, but the ~original~
>encoding and semantic of the character sequence. That is; many (8-bit)
>character codes have a semantic that is CP-dependant.
No, a DOS directory entry is 32 bytes each of 8 bits. If the directory
is moved between systems, for example, only the values of the bits are
preserved; they are fundamental. In positions 1 to 11 of 1-32, the
values of those bits are partly dependent on the code page in use when
that part of the entry was last written.
AFAIR, the bytes that are *explicitly* allowed in traditional DOS file
names have glyphs independent of code page, at least for Western code
pages.
The FAT is something else, containing mainly (non-Pascal) pointers to
disc clusters.
>> However, you are saying that the presence of (codepage 437; shift-and-3
>> to us) #156 = £ (GBP), which behaves normally in true DOS,
>
>No, it only "behaves normally" in a DOS when the active CP maps the SIGN> character to codepoint #156. If a filename generated by CP 437 and
>containing #156 was read on a DOS with, say CP866 (DOS Russian) active, then
>it would be read as , and clearly the original
>file name has been mis-represented.
The #156 behaves normally in DOS, AFAIK; the visual representation may
change.
> This is the primary reason that Win32 no
>w uses Unicode to represent file and folder names; to make then portable
>across machines.
>
>> is enough to generate a LFN entry in Win32?
>
>Most definately.
>
>> If so, that may be a case of having an LFN that does not necessarily need
>> to be counted as such.
>
>Yes, but only if you're not concerned with portability accross CP's.
Such considerations are encompassed by "not necessarily"; and not all
CP-dependent characters change with every page of CP.
>The only definative way is to use an LFN-capable unit (such a my GDOS.PAS -
>see sig) running on an LFB-capable system, and compare the (all uppercase)
>SFN against the true (case-preserved) LFN.
That's too strong. One needs to do the comparison, and its results will
be the same however the strings were obtained.
But consider two files, $3 and £3 (USD 3 & GBP 3); $3 needs 32 bytes of
directory, as does £3 in DOS; both should be readable in Win32. You say
that, created in Win32, £3 will have a LFN (I agree); but AFAICS it will
look identical to the SFN.
I'm wondering whether the _original_ question as asked was fully
representative of the _original_ situation.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
TP/BP/Delphi/&c., FAQqy topics & links;
RAH Prins : c.l.p.b mFAQ;
Timo Salmi's Turbo Pascal FAQ.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
