Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!necntc!ames!ucbcad!ucbvax!CITI.UMICH.EDU!tom From: tom@CITI.UMICH.EDU Newsgroups: comp.protocols.appletalk Subject: MacNFS's file mapping. Message-ID: <8707180836.AA08341@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 10:45:00 EDT Article-I.D.: ucbvax.8707180836.AA08341 Posted: Fri Jul 17 10:45:00 1987 Date-Received: Sat, 18-Jul-87 20:56:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 163 The problem in accommodating both Macintosh and UNIX file system semantics breaks down into four areas: storage of the data, resource, and finder info forks; format of text files; mapping of file names; and storage of desk top information. Solutions to this problem have been attempted by the people who do the A/UX toolbox in their file copy utility, Columbia University in their UNIX AppleShare file server, and the University of Michigan (CITI) in our MacNFS client. I. STORAGE OF THE DATA, RESOURCE, AND FINDER INFO FORKS 1. Storing the forks in separate UNIX files. A/UX, aufs, MacNFS, EFS, and TOPS all use this approach. A/UX divides a Macintosh file "mfile" into two UNIX files: the data fork goes into a UNIX file "mfile", and the info and resource forks are combined into a UNIX file "mfile.res". aufs uses subdirectories ".resource/" and ".finderinfo/", so the three forks are stored in "mfile", ".resource/mfile" and ".finderinfo/mfile". One drawback here is that it's not readily apparent whether a file has resource or info forks. MacNFS puts the data fork in "mfile", the resource fork in "mfile.RF", and the info fork in "mfile.IF". This follows a convention established in the earlier EFS. Having many forks in the same directory complicates some aspects of NFS, although it simplifies others. At CITI, we originally thought that placing the fork files together in a directory would make them easier to manipulate: we were thinking especially about wild carding ("mfile*"). Experience has shown that this feature is not often used, and that the file system clutter is considerable. The choice of subdirectories seems a favorable solution, trading some ease of manipulation for less directory clutter. And it's not hard to imagine simple tools -- mrm, mcp, mmv -- for file manipulation on the UNIX side. 2. Storing the forks in a single file. A suggestion has been made that all three forks can be stored in one UNIX file, with the offset to each fork stored at the beginning of the file. The goal of mapping between Macintosh and UNIX file system semantics is to allow two-way access to files. Macintosh users must be able to use native UNIX files stored on the server, and UNIX users must be able to use Macintosh files stored on the server. This use must be transparent, or the UNIX server is nothing more than a file store. Further, manipulation of the file by MacNFS requires expensive network traffic and complicates a piece of code that has size restrictions. Nothing is gained by making UNIX files second-class citizens from the Macintosh side. We can do much better if we store the forks in separate files. 3. Other issues. What if there is no resource fork? Should an empty resource file be created on the server? At CITI, we think not. MacNFS doesn't require the existence of a resource file when that fork is empty. The alternative requires a ghastly number of file creates when mounting, say, /usr/src/bin. What if there is no data fork? A UNIX file is pure data fork (if you squint right), so it seems reasonable to equate an empty data fork with an empty UNIX file. MacNFS always creates the datafork. And it sure simplifies the code, whether or not other forks are stored in subdirectories. II. FORMAT OF TEXT FILES. Since the Macintosh and UNIX use different characters to terminate lines, we need a standard format for storing text files on UNIX. We also need to decide when translation occurs. aufs does not translate text files at all -- translation is left up to users. Therefore, a user on either system sometimes has to know the format of a file before using it. MacNFS translates text files as they are read and written, interchangingand . The tricky part is deciding when a file contains straight text. MacNFS allows a user to set certain options when a volume is mounted. One pair of options sets the default file type and file creator, which are used for UNIX files that don't have finder info forks. Another option allows a user to declare the file type for which translation will occur. Normally, we set both the default file type and the translation file type to 'TEXT'. This interoperates well with the UNIX notion of a "text file", i.e., any regular file, but presents problems when accessing UNIX binary files, such as font bitmaps or other graphic objects. The user can prevent translation of a UNIX file by usings a desk accessory such as SetFile to give the UNIX file a type other than TEXT before the file is read. At CITI, we have considered inspecting the first part of a file to decide whether it's TEXT or DATA, like the UNIX "file" command, but the necessary network traffic appears to preclude efficient implementation on the client side. This sort of thing may be feasible for aufs, since the server can be modified to peek at the file. III. FILE NAME MAPPING. MacNFS uses the following translation scheme. First, since `:' is not a legal character in Macintosh file names, and `/' not legal in UNIX file names, they are uniformly interchanged. Thus a Mac file "abc/def" looks like "abc:def" from the UNIX side. Similarly, a UNIX file called "abc:def" looks like "abc/def" on the Macintosh. Other special characters in Macintosh file names are encoded as "^XX" on the UNIX side, where "XX" is the hexadecimal encoding of the character. E.g., the hexadecimal encoding of TM, the trademark symbol, is 0xAA, so TM is represented as "^AA". A problem arises if a Macintosh file name contains the character sequence "^XX" for a valid hexadecimal sequence. E.g., a Macintosh file named "ab^62c" copied to a UNIX file server becomes "abbc" when viewed from the macintosh again. CITI has no idea how to live within the 14-character name length constraint imposed by System V file systems. IV. DESK TOP INFORMATION. aufs implements the shared volume calls that provide the desk top information to the Finder. The desk top information is stored in the UNIX files .ADeskTop and .IDeskTop in the root directory of the mounted volume. In MacNFS, the finder uses direct reads and writes to "DeskTop" and "DeskTop.RF" in the root directory of the mounted volume. But we plan to follow Columbia's lead and implement the shared volume calls, storing the information in a file somewhere in the root directory. With that done, we will have control over the format of the DeskTop file MacNFS creates. Both aufs and MacNFS make it difficult to mount read-only volumes. At CITI, we toyed with keeping the DeskTop in RAM -- the code got very hairy and we dropped it. But the ability to mount read-only volumes would be A Good Thing. Tom Unger Send comments to: MacNFS@citi.umich.edu