Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!sri-spam!ames!sdcsvax!ucbvax!CITI.UMICH.EDU!tom
From: tom@CITI.UMICH.EDU
Newsgroups: comp.protocols.appletalk
Subject: Re: Mac file Representation Update
Message-ID: <8709100123.AA20981@ucbvax.Berkeley.EDU>
Date: Tue, 8-Sep-87 09:58:00 EDT
Article-I.D.: ucbvax.8709100123.AA20981
Posted: Tue Sep  8 09:58:00 1987
Date-Received: Fri, 11-Sep-87 07:24:31 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 69

Rich,

My response to your latest posting.  The gist of my comments is due to
the fact that in MacNFS, *all* processing is done on the Mac side;
there is *no possibility* of doing any work on the remote side (except
for i/o).

> 5)  We will "suggest" that creators of AppleSIngle and AppleDouble Header files
> keep info like file attributes, real file name, Finder Info, etc. as close to
> the header as possible, but there is no way to enforce it.

If it is possible for people to put the crucial information off in some
odd place in the file (away from the header) someone will.  Rather than
add code to MacNFS to deal with those special cases I am inclined to
reject those files that do not meet the guidelines.  Still, it is extra
code to test for compliance and reject files.  I would like to see the
file info (finder info and file attributes) and dates in fixed fields
in the header.

> 7)  We dislike the idea of breaking resource forks out into yet another file,

I don't know all the implications of keeping the resource fork in a
file with the file info but I believe that it is workable given the
following guidelines:  The resource fork must be the last item in the
file and it's descriptor must be near the header such that we can read
it when we read the header information (preferably a fixed field).  I
still prefer breaking resource forks into separate files.

> 11)  If the Macintosh file does not contain a resource fork, then the
> AppleSingle or AppleDouble file may contain a resource ID entry of
length > zero bytes, or it may contain no entry descriptor at all.

Again, a special case to handle when creating a resource fork.  If
there is no descriptor I have to create one.  If there is no space for
a new descriptor I have to munge the file to make space.

> 12)  We are currently rethinking our restriction about not using subdirectories.

I used to think putting all the files in one directory was the better
approach until I actually used it.  Now I prefer subdirectories.  Both,
however, are workable, but UNIX people are fairly insistent that the
clutter resulting from not using subdirectories is a major headache.


General observations:

There are two problems you are trying to solve:  archiving files on a
foreign file system and a storing mac files on a foreign for use with
an external file system.  To solve the first problem we need a general
extensible format that makes few assumptions about the file formats
which AppleDouble provides.  To solve the second problem we need a
macintosh specific format that allows for quick storage and retrieval
of Macintosh file information.  Few assumptions about services provided
by the foreign file system should be made.  AppleSingle is not the
solution that I would like to see.  It retains un-needed generality,
allowing too many variations in the file format.  Each variation is a
special case that must be dealt with.  This introduces additional
complex code that is ripe for bugs.  A simple, fixed, macintosh
specific format would side step all these problems.

MacNFS has tighter size constraints than Charlie's aufs server, our
memory comes from the application space.  Adding code to deal with
special cases in the file format further reduces the memory available
for applications.


Tom Unger
tom@citi.umich.edu
Univeristy of Michigan, CITI