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,
interchanging  and .  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