croft@SAFE.STANFORD.EDU (Bill Croft) (07/14/87)
Rich Andrews at Apple (one of the Appleshare developers) would like to know how the various file servers on UNIX (and elsewhere) store the components of a Mac file (data fork, resource fork, finder info). It appears that each file server is implementing this differently. It might help if there was some standardization in this area. Could the file server developers each reply to Rich (and info-appletalk) with a brief rational for their choices? Hopefully we'll get responses from Columbia (CAP/Aufs), UMich CITI (MacNFS), Centram (TOPS), Alisa (VMS file service), etc. To mention in passing: John Seamons at LucasFilm chose for his original EFS server to store the components of a Mac file (for example named 'foo') as: foo.DF (data fork) foo.RF (resource fork) foo.IF (finder info) This is a very simple scheme, and I think has some advantages over trying to 'hide' these details from the user, as CAP/Aufs does with '.resource' and '.finderinfo' subdirectories. ------- Forwarded Message Date: Sat, 11 Jul 87 14:41:19 pdt From: Richard Andrews <andrews%apple.csnet@RELAY.CS.NET> To: croft%safe@ARGUS.STANFORD.EDU Subject: file server survey When you put a Mac file on some other file system that doesn't support dual- forked files, in what format should it be stored? Some kind of unary format (data, rsrc, forks and finder info crammed into one file); file-per-fork with invisibility of the resource fork; directory containing several files; etc.??? I have managed (I think) to get myself connected to the bulletin board comp.protocols.appletalk and apple.general, but I haven't figured out how to post a message. Could you do that for me, and ask people to send their suggestions directly to my account? I will collect all the info and discuss it with a working group here at Apple. Hopefully, Apple can come up with a recommendation that will satisfy most people. Thanks for your help, Rich ------- End of Forwarded Message
elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (07/14/87)
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
croft@safe.stanford.EDU (Bill Croft) (07/14/87)
Chris forgot to cc: info-appletalk... ------- Forwarded Message Date: Tue, 14 Jul 87 09:05:04 EDT From: Chris Maio <chris@columbia.edu> 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
jww@sdcsvax.UCSD.EDU (Joel West) (07/15/87)
Does anyone know how this is being handled under A/UX? I'd
heard it was
Foo
Foo.rez
/* trash the Info */
--
Joel West, Palomar Software, Inc. (c/o UCSD)
{ucbvax,ihnp4}!sdcsvax!jww or jww@sdcsvax.ucsd.edu