Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!osu-eddie!elwell%tut.cis.ohio-state.edu
From: elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP
Newsgroups: comp.protocols.appletalk
Subject: Re: Mac file components on non-apple file servers
Message-ID: <3805@osu-eddie.UUCP>
Date: Tue, 14-Jul-87 12:53:13 EDT
Article-I.D.: osu-eddi.3805
Posted: Tue Jul 14 12:53:13 1987
Date-Received: Thu, 16-Jul-87 01:23:52 EDT
References: <8707132308.AA17913@ucbvax.Berkeley.EDU>
Sender: news@osu-eddie.UUCP
Reply-To: elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (Clayton Elwell)
Distribution: world
Organization: The Ohio State University, CIS Dept.
Lines: 53

Well, let's see.  We are a beta test site for UNIX TOPS and the A/UX toolbox.
I am also currently hacking on a prototype AFP server (no, no one else can
have it yet :-)).  Here are my thoughts on each of the basic schemes:


Scheme #1: Subdirectories for resource forks and/or finder information.

This scheme is used by UNIX TOPS and the CAP (preliminary, I hope) AFP server.
It means that UNIX files stuck into a directory being used as a Mac volume will
just show up as files with data forks but no resource forks.  This is a good
thing, especuially if the software is smart enough to recognize text files
and translate CRs to NLs on the fly.  However, it's hard to explain to a naive
user what's going on.


Scheme #2: Separate files for the different forks, but stored in the same
directory.

This scheme is used by the A/UX toolbox and SUMEX C/macput/macget.  This
is easier to explain to a UNIX user, but scanning the directory (to return
a list of files to the Mac) becomes trickier.  Also, since it is done by
tacking things on to the file name, it exacerbates the long name/short name
problem.


Scheme #3: Store everything in one file, sort of like a "partitioned data set"
from IBM days.

This hides the Mac file system structure from the UNIX user, but makes
trading files harder.


Personally, I think that #1 or #2 is the way to go, but they both have their
own disadvantages.  #3 is right out as far as I'm concerned--too complex.

I'm currently using #2, mainly so that I can maintain compatibility with A/UX,
so that local programs can run on the same file system as remote clients do
(a big win).

While we're going over this stuff, we should also try and codify (or ask Apple
to codify) when it is kosher to squirrel away Directory IDs, so that we can
figure out whether or not file servers need to maintain persistent HFS data-
bases, as opposed to just making up DirIDs on the fly (which works pretty
well, based on empirical testing).


-=-

Clayton Elwell

Arpa/CSNet:	Elwell@Ohio-State.ARPA
UUCP:		...!cbosgd!osu-eddie!elwell
Voice:		(614) 292-6546