Date: Fri, 2 Aug 1996 17:31:07 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: anyone working on upgrading the msdosfs to NetBSD levels? Message-ID: <199608021531.RAA00207@eac.iafrica.com> In-Reply-To: <199608020043.RAA04852@phaeton.artisoft.com> from "Terry Lambert" at Aug 1, 96 05:43:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> When a name is passed in, it is either capable of being a valid
> 8.3 name or it isn't. If it is, then the name is looked up in
> the 8.3 name space. For an 8.3 name, the LFN will always be
> the same as the 8.3 name.
There is the complication of legacy directory entries (or those
created when running Win95 in "MS-DOS 7" mode -- without "Windows"
loaded.)
For example, "FILE ONE.TXT" is "capable of being a valid 8.3 name"
(in the sense that it can legally occur in the short name space,
and -- having no LFN -- must be looked up there.) However, when
created in a DOS window, it becomes "FILEON~1.TXT". By this
criterion of what constitutes an 8.3 name, the LFN won't necessarily
"always be the same as the 8.3 name".
Incidentally, this anomaly in the handling of legal 8.3 names allows
a situation to develop where the same name exists in the short name
space and in the long name space, but refers to different files:
RUNME~1 COM 3,380 06-17-94 1:03a RUN ME.COM
RUN ME COM 15,118 10-18-91 1:01a RUN ME.COM
> Note that the 8.3 name is a case
> insensitive name; a name "Foo" and "foo" are identical for case
> insensitive lookup/case sensitive storage; they are the valid
> short name "FOO".
>
> The short name lookup will match or fail to match. In no case is
> it possible for a valid short name to have a long name form that
> collides with another long name form. Short names are looked up
> in the short name space and in the long name space. The long name
> space lookup is done because of the direction collisions are
> handled.
I gather, though, that the long name space lookup is done first.
(And, because of this -- in the above example -- Win95 and DOS will
find and run different files.)
> In the LFN case, the lookup is done in the long name space. This
> is because any LFN that comes into lookup will have an LFN form
> if it has been previously stored. In the LFN case, the short name
> is not examined.
OK. Which can actually break legacy DOS applications that use > 8.3
names to refer to existing files. Previously "Description.ASCII"
would find "DESCRIPT.ASC" in the short (ie. only) name space, but
this no longer works without converting the directory entry to create
an associated LFN.
>
> The long file name that does not match in the create case will be
> cannonized to a tentative short name by searching for a '.' seperated
> suffix from the right side of the LFN moving left.
>
> The long name up to the first period, or 6 characters, will be copied
> moving right.
However, the order in which this is done is important. For example,
".profile" results in "PROFIL~1" not "~1.PRO".
There is also other name mangling: for instance, the stripping of space
characters, and replacement of illegal 8.3 name characters: eg.
"c++.exe" -> "C__~1.EXE".
>
> The last two characters preceeding the suffix are replaced with a
> provisional "tail" value: "~1".
>
> Thus:
>
> ThisIsALong.Named.Document -> THISIS~1.DOC
> VeryLongName.TXT -> VERYLO~1.TXT
> Short.doc -> SHORT.DOC (8.3 name on input)
>
>
> The tail is permitted to increment based on collision, "eating" the
> characters leftward.
But only if "eating" is necessary. Thus, following "FILE~9.TXT" would
be "FILE~10.TXT", not "FIL~10.TXT".
> Windows95 and WindowsNT have support routines
> for VFAT that do all of this for you.
>
> For instance, "VeryLongName.TXT" has a tentative short name with
> a provisional numeric "tail" of "VERYLO~1.TXT". Now if there already
> exists a "VERYLO~9.TXT", the next allowable post-collision value is
> "VERYL~10.TXT".
>
> This requires that your pattern match match the suffix (".TXT"), then
> go through matching "VERLO" for all possible tail vales that already
> exist. This requires a full traversal of the short name space for the
> directory. Windows95 wimps out and uses a "max" value on the tail,
> so if you had "VERYLO~8.TXT" but no "VERYLO~1.TXT", it would still
> end up with the post-collision name "VERYLO~9.TXT".
Apparently this isn't (at least any longer) the case:
VERYLO~8.TXT VeryLongName8.TXT
copy VeryLongName8.TXT VeryLongNameToo.TXT
VERYLO~1.TXT VeryLongNameToo.TXT
VERYLO~8.TXT VeryLongName8.TXT
(To use attempt to wimp out and rely on a "max" value would only invite
problems, since a "~9999999.TXT" could be present.)
Thanks for all this, Terry.
Incidentally, I have a note somewhere relating to VFAT on Linux
and a "-posix" mount option. (Apparently it is intended to enable
full case sensitivity for LFNs, allowing eg. "longfilename" and
"LongFileName" to coexist. And isn't currently fully implemented.)
Any comments on the desirability of this?
--
Robert Nordier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608021531.RAA00207>