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 MaioTo: 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