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