Appendix A - VINES File System Naming Rules
The VINES File System (VFS) creates name spaces for file system objects (directories, subdirectories, and files) to support heterogeneous file sharing. Heterogeneous file sharing means that, with proper access, users at DOS, Windows, Windows 95, Windows NT, OS/2, and Macintosh workstations can view and manipulate files created under different file systems.
The name spaces are based on the file systems that VFS supports: DOS and OS/2 FAT (File Allocation Table), Windows 95 Protected-mode FAT (VFAT), Windows NT File System (NTFS), Macintosh, and UNIX. Use these rules to remember how VFS resolves names:
If a file system object is created at a Macintosh, VFS follows the AppleTalk Filing Protocol (AFP) naming rules. If a file system object is created from a Windows 95 or Windows NT client with a long file name, two names are associated with the file; a long file name and an auto-generated alias in MS-DOS standard 8.3 format. If a file system object is created from any other file system, VFS follows the XOPEN naming rules. If the above processes did not create a UNIX name, a UNIX name is created.
The easiest way to minimize naming problems is to create names that follow the rules of the strictest file system (DOS and OS/2 FAT).
VFS currently supports five file system views: DOS and OS/2 FAT, Windows 95 Protected-mode FAT, Windows NTFS, AFP (AppleTalk Filing Protocol for Macintosh), and UNIX. The UNIX file system is supported only for VINES toolkit users and for Banyan Enhanced UNIX Access.
Each file system has naming rules that affect the following:
Case Sensitive - A case sensitive file system recognizes the difference between upper- and lower-case letters and therefore treats filenames that are identical - except for case - as different files. For example, UNIX treats book, BOOK, and Book as three different files. UNIX also preserves the case that you enter.
Case Insensitive - Case insensitive means that a file system does not recognize a difference between upper- and lower-case letters and therefore does not perceive a name typed in all lower-case letters, as being different from the same name typed in all upper-case or mixed-case letters. For example, case insensitive file systems would see BOOK, Book, and book as the same file.
In addition, case insensitive file systems display filenames differently:
DOS FAT lets you enter upper- or lower-case letters; however, DOS converts any lower-case letters you enter into upper-case letters. In other words, DOS does not preserve the case that you enter. For example, if you enter book, DOS displays the name as BOOK. Windows 95, Windows NT, and Macintosh let you enter filenames using upper- and lower-case letters, and do preserve the case that you use. For example, if you enter Book, these clients display the filename as Book.
Macintosh Delimiters - The Macintosh operating system uses a colon as a delimiter between disk, folder, and filenames. If you use two colons in a filename (for example, Acctg:Jan:Rept), the operating system treats the text before the first colon (Acctg) as a disk name, the text between the two colons (Jan) as a folder name, and the text after the second colon (Rept) as the filename.
Special Characters - In UNIX the slash (/), asterisk (*), brackets ([ ]), and question mark (?) characters have special meaning to the operating system. While the slash is the only character you cannot use in filenames, you should avoid using any of these special characters in filenames.
VFS Special Character - VFS uses the bang (!) character at the beginning of the DOS name of a file to indicate that a Macintosh name has been changed to accommodate DOS rules. The bang character is valid in both the DOS and Macintosh file systems. If it is part of the original Macintosh name, VFS does not use it at the beginning of the DOS name.
Table A-1 summarizes the file naming rules for the operating systems VFS supports.
Table A-2 summarizes what happens when a user, working in the file system named in the left column, creates a file. The rules affecting the name assigned to the file under other file systems are shown in the other columns. For example, when a user creates a file from a Windows 95 workstation, the DOS view is an auto-generated alias, or short name and is in all upper case. LFN in the table refers to Windows Protected-mode FAT (VFAT) and Windows NTFS.
When you create a file with a long name (LFN) at a Windows 95 or Windows NT workstation, VFAT and NTFS uses these rule to create names for other views:
If the name is 31 characters or less, the Macintosh view is the same as the LFN view. Otherwise, the Macintosh view is the same as the DOS view. If the name does not meet the DOS 8.3 format, remove any characters that are invalid in the DOS view and replace them with an underscore ( _ ). Also, remove all spaces and all periods except the last one. Truncate the string before the period, if there is one, to six characters and append to that the string ~1. Truncate the string after the period to three characters. If the resulting generated name duplicates an existing name, increment the ~1 string.
The following examples show how file names appear in the different name spaces. Windows 95 and Windows NT clients are referred to as LFN clients in the examples. The examples assume that the filename being created does not already exist in another name space.
Example 1 - File Name Created from LFN Client
Create the file "Long File Name.Txt" from an LFN client and the views may be as follows:
LFN client, Macintosh Long File Name.Txt DOS, Windows 3.x, OS/2 LONGFI~1.TXT UNIX longfi!1.txt
VFS automatically creates an alias, or short name, for the DOS view to conform with the DOS 8.3 format requirements.
Create the file "Long File Name with more than 31 bytes.Txt" from an LFN client and the views may be as follows:
LFN client Long File Name with more than 31 bytes.Txt Macintosh LongFi~2.Txt DOS, Windows 3.x, OS/2 LONGFI~2.TXT UNIX longfi~2.txt
Because the file name is longer than 31 bytes, the alias appears in the Macintosh view.
Copying Files with Long File Names from Different File Systems
Manipulation of files with long names such that the names are affected, when carried out in a non-LFN view, results in destroying the long name for the file. Commands, such as COPY, RENAME, MOVE, and SAVE AS from EDIT, when done from DOS, Windows 3.x, or OS/2 clients results in the destination file having the same view of the file as the FAT view where both the alias and the long name are the same. Use VCOPY to copy files with long names to preserve the long name.
If a DOS client does a COPY of LONGFI~1.TXT from the file name in Example 1 above, the file name of the destination file will appear as LONGFI~1.TXT in the DOS, Windows 3.x LFN, and OS/2 views and the original file name, Long File Name.Txt, is lost.
Similarly, if you copy a file with a long name from a Macintosh client, the destination preserves the Macintosh view of the name and regenerates the FAT view, if necessary, using the existing Macintosh short name generation procedure. VFS uses the existing Macintosh short name generation procedure because VFS also preserves the view of the client creating the name.
Thus, if a Macintosh client copies Long File Name.Txt from Example 1 above, the file name of the destination file will appear as follows:
LFN client, Macintosh Long File Name.Txt DOS Windows 3.x, OS/2 !LONG_FI.LE_ UNIX !long_fi.le_
VFS generates the alias, or short name, differently, using a ! and not a ~ because the creator of the file was in the Macintosh view.
When you create a file at a Macintosh workstation, VFS uses AFP rules for creating names. In summary, AFP rules state:
For file sharing, there are two names, Macintosh long and short (generally, DOS FAT). All folders (directories) and files have both Macintosh long and short names. The names may be the same or they may be different.
If the Macintosh name is a valid short name (that is, 8.3 DOS), then the long (Macintosh) name and the short (DOS) name will be the same. If the name given a file at a Macintosh is not a valid short name (too many or invalid characters) and does not match any existing long name, a short name is created from the Macintosh name. If the Macintosh name is too long, it will be truncated. Most characters that are invalid in DOS will be dropped, but some may be mapped to valid characters. The details of the truncation and mapping are not spelled out in the AFP specification, and may differ between implementations. Furthermore, truncation and mapping may also depend on filenames that already exist.
The following examples show how file names appear in the different name spaces. Windows 95 and Windows NT clients are referred to as LFN clients in the examples. The examples assume that the filename being created does not already exist in another name space.
Example 2 - File Name Created from Macintosh Client
The Macintosh name applies to the LFN view unless the Macintosh name consists of characters that are not valid in the LFN view, in which case the LFN view is the case-preserved FAT alias generated name.
Create the file "Long File Name.Txt" from the Macintosh and the views may be as follows:
LFN client, Macintosh Long File Name.Txt DOS Windows 3.x, OS/2 !LONG_FI.LE_ UNIX !long_fi.le_
Create the file "Long\File Name.Txt" from the Macintosh and the views may be as follows:
Macintosh Long\File Name.Txt LFN client !LongFil.e_N DOS, Windows 3.x, OS/2 !LONGFIL.E_N UNIX !longfil.e_n
VFS currently uses XOPEN rules in all file creations except when a file is created at a Macintosh, Windows 95, or Windows NT workstation. XOPEN does not allow truncation of a filename, nor does it allow mapping of invalid characters. If a filename created in one file system violates the rules of another system (too long or invalid characters), the file will not be visible in the more restrictive file system space.
If a name is created in a case-insensitive file system (DOS), then it will appear all lower-case in a file system that is case-sensitive (UNIX). The DOS name BOOK would appear in UNIX as book.
If a name is created in a case-sensitive file system (UNIX), then it will appear in a case-insensitive file system (all other views) only if the name is all lower-case. A name with any upper-case characters created in UNIX, then, would not have a corresponding name in the other views. Other users would not see the UNIX file.
In XOPEN rules, remember that, if a name is valid, you can see it. VINES toolkit users should note that VFS supports only lower-case characters from UNIX; that is, when a file is created in UNIX, only the lower-case characters are valid Macintosh, DOS, and OS/2 names. Therefore, if you name files in UNIX with mixed case or all upper-case, you will not be able to see those files in any of the other views.
The following example describes how file names appear in the different name spaces.
Example 3 - File Name Created from DOS, Windows 3.x, or OS/2 Clients
File names created from these clients and from pre-VINES 7.0 clients have the same long name view as the FAT name for the file. Thus, FATFILE.TXT appears as FATFILE.TXT to all of the clients. In UNIX, it appears as fatfile.txt.
The following lists the rules that VFS uses to create names across the network:
1. If you can see a file and you have the proper access rights, you can rename that file. If you change a filename under one file system, the filename automatically changes under all file systems.
2. If a Macintosh name is created because some other file system user created a file, it does not cause a DOS name to be created using AFP rules. A DOS name is created from a Macintosh name only when a Macintosh user creates the file.
3. File creation can fail due to a collision in another name space. For example, suppose a Macintosh user creates 12345678901234. A short name such as 12345678.901 is created, and that name is assigned to DOS and UNIX. (This is done even though UNIX could use the original name.)
The Macintosh user cannot now create a file 12345678.901 for two reasons:
- Because this name is valid in the short name space, it must be used there.
- The name already exists in the short (DOS) name space.
UNIX cannot create a file 12345678901234, because that name must appear in the Macintosh space, and it already appears there.
4. Two different files can have the same name in two different name spaces, except for Macintosh and DOS. AFP specifically says that if a name appears in both the short (in VFS, DOS) and long (in VFS, Macintosh) name spaces, then it must name the same file. For instance, UNIX can create BOOK, which will not appear in DOS. DOS can then create BOOK, which will appear in UNIX as book. The two files named BOOK are different.
Be sure you understand the difference between rules 3 and 4.
AFP refers to a short name space and a long name space. The long name space is the VFS Macintosh space, and the short name space is the VFS DOS space. A Macintosh application using the short name is using DOS names. There is no Macintosh short name space separate from the DOS name space.
DOS has a file attribute hidden, which prevents the filename from being returned by a DIR command. This attribute and other attributes that affect the visibility of names (for example, the system attribute) are ignored by file systems that do not have an analogous concept. So, if a DOS user sets hidden on a file, the filename vanishes from the user's DOS view but not from any UNIX view. (This rule is an XOPEN specification.)
When a file service is created, all file system types are supported (DOS, VFAT and NTFS long file names, Macintosh, UNIX, non-HPFS OS/2). DOS, VFAT, NTFS, non-HPFS OS/2, and Macintosh names always have a view in the other name spaces. Every file and directory created has a UNIX name for internal purposes (for example, for use by VINES backup/restore).
Under UNIX, a file may have multiple names if it has been linked to other filenames. VFS treats these files in the same way it treats any UNIX file.
