From owner-freebsd-hackers Fri Aug 2 08:35:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA13369 for hackers-outgoing; Fri, 2 Aug 1996 08:35:04 -0700 (PDT) Received: from eac.iafrica.com (196-7-101-145.iafrica.com [196.7.101.145]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA13351 for ; Fri, 2 Aug 1996 08:34:33 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id RAA00207; Fri, 2 Aug 1996 17:31:09 +0200 From: Robert Nordier Message-Id: <199608021531.RAA00207@eac.iafrica.com> Subject: Re: anyone working on upgrading the msdosfs to NetBSD levels? To: terry@lambert.org (Terry Lambert) Date: Fri, 2 Aug 1996 17:31:07 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199608020043.RAA04852@phaeton.artisoft.com> from "Terry Lambert" at Aug 1, 96 05:43:14 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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