🚀 go-pugleaf

Following is a summary of the response we sent to Apple for the
original posting and a copy of the message we send in response to the
update.

A brief summary of message we sent in response to the original posting
(but not posted to info-appletalk for a number of reasons) is:
 * proposal is basically okay, but have following mods that make it
more platable
     - re: file naming
	o subdirectories are a way of naming files conviently
	  (os dep, but the naming is already os dep so who cares?)
	o prepending or suffixing chars to distinguish is more expensive
	  for servers
     - combining resource & finderinfo in appledouble
        o causes problems with semantics on file operations
	o proposed using a tag in the resource field that marks whether
	  resource file is included in the appledouble file
     - holes are problematic since they get filled (on copies)
     - need basic information about file near top of file so we can get
       in fewer reads
     - want file protections in afp client (if server says it handles them)
	(unlikely)

I've added some corrections in "[]"'s.

Date: Fri, 4 Sep 87 11:13:52 EDT
From: Charlie C. Kim <cck>
To: andrews@apple.UUCP
Subject: Re: Mac File Representation Update
Newsgroups: comp.protocols.appletalk
In-Reply-To: <6131@apple.UUCP>
Organization: Columbia University Center for Computing Activities
Cc: tom@citi.umich.edu, cck, bill

>2)  I think this means that we must define two different Home File System
>values for unix, since it runs on processors that use both ordering schemes.

This is sufficient for some binary data, but not for the general case
since different versions of unix [on different machines] have
different magic numbers, different sizes for floats, ints, etc.  The
issue is two-fold: files have some os dependent features (obviously)
and data encoded in files have machine dependenet [dependent]
features. You would be better served by adding a "machine type" that
has a map of "machine attributes" (like the Adobe AFD files for
PostScript machines) if you want to attempt to services [service] this
particular requirement.  In addition, there is a (lesser) need for
such a map for ["for" should be "of"] OS dependent features that
contain information about file name representations, end of line
mappings, etc.

>3)  Someone claimed that "holes" in a file are not useful since someone may
>copy the file and not preserve the holes.  Our feeling is that it is more 
>general to allow them, and nothing is gained by prohibiting them.
Just to set the record straight.  No complaints about allowing holes -
just noting the problem with them - the real problem under Unix is
that it is not possible to determine if a file has a hole in it and
entire paradigm is somewhat contradictory to the stream of bytes
philosphy of Unix files.  It's a particular problem if someone blithely
leaves a lot of space to allow for expansion.  Since the file formats
are designed for files that will be copied around, this should be at
least noted in the specification since the document suggests the use
of holes.

>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.
Yes there is.  Make them required entries that are defined as part of the
header - e.g. make them fit into fixed positions.  The "strong"
suggestion is good enough for me though.  This is simply a
issue of efficency and ease of programming. [Still prefer the "hard"
approach, it makes life much less complicated]

>7)  We dislike the idea of breaking resource forks out into yet another file,
>since two files is enough to have to worry about.  Shifting the resource fork
>entry to the end of the file to allow easy munging should be easy.
Yes, the key word is munging.  You have to play a lot of games to make
this work.  Every fork operation becomes a special case - some even
problematic (e.g. seek from end backwards or byte range lock entire
file).  You may not think this is a problem, but it is for us, Aufs is
already over 11,000 lines of code (too much) and biggest single
segment of this code (~4,000 lines) is that which maps the unix
to/from AFP semantics.  If you are going to allow holes, you might as
well allow split resource files.  [Okay, so this really isn't an
argument] The tradeoff is a time-space one, but in our case it is a
big time gain in relation to a small space loss.  If I'm willing to
deal with three files, why don't you let me?  As long as there is a
consistent method for figuring out where the files are, this is no
problem. [e.g. os dep. naming policy]

In addition, by using a "tag" that indicates that the fork exists
outside this file, you will have compressed the AppleSingle and
AppleDouble formats into an integrated format.  Also, while there is
no single standard that will encompass all file naming schemes
required, there is no reason not to define a some number of them and
encode them as the "tag" values valid for one or more OSes.  This
would allow different file name representations to co-exists [sorry,
"co-exist"] on a particular systems [woops, "system"].

Charlie C. Kim
User Services
Columbia University