Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ucbcad!ucbvax!safe.stanford.EDU!croft
From: croft@safe.stanford.EDU (Bill Croft)
Newsgroups: comp.protocols.appletalk
Subject: re: Mac file components on non-apple file servers
Message-ID: <8707142025.AA08060@ucbvax.Berkeley.EDU>
Date: Tue, 14-Jul-87 16:09:00 EDT
Article-I.D.: ucbvax.8707142025.AA08060
Posted: Tue Jul 14 16:09:00 1987
Date-Received: Thu, 16-Jul-87 07:01:24 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <@andrew.cmu.edu:croft@safe.stanford.edu>
Distribution: world
Organization: The ARPA Internet
Lines: 68

Chris forgot to cc: info-appletalk...

------- Forwarded Message

Date: Tue, 14 Jul 87 09:05:04 EDT
From: Chris Maio 
To: andrews%apple.csnet@relay.cs.net
Cc: croft@safe.stanford.edu
Subject: Mac file components on non-apple file servers

Charlie Kim or Bill Schilit (the aufs authors) will undoubtedly reply to give
you their opinion, but I've given some thought to possible changes for aufs
(e.g. to make it usable on filesystems limited to 14 character names), so
I thought I'd offer my two cents worth.

To Bill Croft: aufs uses the "hidden" .resource and .finderinfo directories not
to hide details from the user, but to make aufs more useful for browsing normal
UNIX directories as well as Macintosh files.  The fact that it doesn't do
lf->cr translation on vanilla UNIX text files was, I think, something that the
developers just never got around to doing.

Any scheme which depends on a one-to-one mapping between UNIX and Macintosh
filenames will have problems on systems with System V filesystems.  This
suggests that some sort of alternate filename lookup should be used; for
instance, using a separate file in each directory to map Macintosh filenames to
UNIX filenames.  This map file might also be used to record other information,
such as DirIDs, access passwords, etc.

It's not obvious to me why there are two separate files for the resource and
finder info data, aside perhaps from the precedent set by MacTerminal and the
UNIX macget utility; it seems to me that it would be simpler to use just one
file, where the first n bytes contain the finder info and references to the
resource fork are offset by n bytes when accessing the actual file.  If a
special file is used to map Mac to UNIX filenames, the finder info field might
be preceded by a UNIX magic number and a Macintosh filename, in order to allow
a UNIX utility to scan a UNIX directory hierarchy to for Macintosh files and
build the filename mapping file from scratch.

To go one step further, it would probably be a useful experiment to instrument
an appleshare server to record patterns of reference to the resource and data
forks with typical applications.  Depending on the results, it may be
reasonable to put both the data and resource forks (and finderinfo) in a single
UNIX file, with the AppleShare server moving things around in the UNIX file as
necessary to keep the two forks from colliding with each other, or implementing
some very simple form of "virtual memory" in the file when it's open, or
perhaps writing the smaller fork of open files to a temporary file.  Some
precautions would be necessary to ensure that such files could be reconstructed
after a crash.  While this may sound hairy, I don't think it would be too hard
to implement, and if I have the time this is what I am thinking of doing with
the aufs server.

In summary, this is what I think the UNIX file format might look like:

	4 bytes		UNIX magic number, file format version number
	32 bytes	Macintosh filename (for rebuilding name map file)
	4+4 bytes	size and offset of data fork
	4+4 bytes	size and offset of resource fork
	nn bytes	private data area for use by the AppleShare server
	mm bytes	finder info
	?		larger of data and resource forks
	?		gap to next filesystem block, maybe larger to allow
				growth of preceding fork
	?		smaller of data and resource forks

Chris Maio
Columbia University

------- End of Forwarded Message