🚀 go-pugleaf

I agree with most of what Charlie Kim said regarding the AppleSingle
and AppleDouble format.  My own comments are as follows.


AppleSingle:

You should specify what an unused entry descriptor looks like.  I
suggest defining an Entry ID for "unused".


AppleDouble:

Putting the resource fork and the finder information in the same file
is something we have considered and I believe that it will work.
However, our plan was to put things at fixed offsets rather than having
a map at the beginning of the file.  If all the important information
could be put in the first n bytes (preferably n <= 512) bytes of the
Header file that would eliminate the need for multiple reads.  The
problem of course is the list of descriptors is variable length, there
is no guarantee that it will not push the important information beyond
the first n bytes of the header file.

If the resource fork is empty, will there be a descriptor for it
pointing to a zero length portion of the header file or no descriptor
at all?  If there is no descriptor, and no empty descriptors, and no
space for a new descriptor it will be alot of work to add a
descriptor.  What if MacNFS comes across a AppleDoube file written by
some other application that did not make the resource fork the last
item in the headerfile?  Expanding the resource fork requires alot of
work.  These and many other awkward cases may crop up unless the format
of the header file is more rigidly defined.  I am reluctant to add code
to MacFNS to deal with them because they are picky format variations
that may occur only ocationally and could have been avoided anyway.

So, putting the finder info and resource fork in the same file will work
but the format needs to be more rigid.

I assume that 68xxx byte ordering in files refers to numbers such as
the offsets and type numbers, not the contents of data and resource
forks.

I don't like having different naming conventions for different
servers.  This is another server dependency that MacNFS will have to
keep track of.  Yet, I am not sure it is possible to devise a single
scheme that works for all server types.  I don't know the answer to
this one.

From the MacNFS view and a user's view, I still prefer putting
the "extra" files in a subdirectory.  For the user, the directories
appear less cluttered.  For the software, counting the files in a
directory is easier.

Tom Unger
University Of Michigan CITI
tom@citi.umich.edu