Re: what are .sdk archives?

[dempson@actrix.gen.nz (David Empson)]

Gregory Weston <uce@splook.com> wrote:

> In article <0Zbdj.199$sE5.47@trndny05>,
>  "Charlie" <charlieDOTd@verEYEzon.net> wrote:
> 
> > "Gregory Weston" <uce@splook.com> wrote in message 
> > uce-374A13.08265128122007@comcast.dca.giganews.com">news:uce-374A13.08265128122007@comcast.dca.giganews.com...
> > > Where would they be, then? You really want each e-mail file to be
> > > accompanied by an arbitrary number of visible ancillary files
> > > representing single headers?
> > 
> > Yes, I believe it is preferable, to forks.  What you see as clutter I see as
> > an open (visible to the user) file system.
> 
> But getting back to what I said above, that leads to either a 
> potentially huge amount of user interaction or a lot of OS magic to 
> maintain the relationship. To me it's very suboptimal for the user to
> see, in addition to their foo.txt file, an unbounded collection of other
> files named foo.txt-xattr-SenderName, foo.txt-xattr-SenderAddr, 
> foo.txt-xattr-Subject, etc. (It may not even be possible, given that we
> have to deal with limits on the lengths of both filenames and full paths
> in most extant file systems today.) Just having them there buries signal
> under noise.

Agreed.

> To then either require that the user rename the files, copy them en masse
> or whatever *or* have the OS do so those manipulations implicitly just
> aggravates the situation.

Mac OS X has been moving away from resource forks and replacing them
with packages (also known as bundles). This is actually a folder (with a
flag bit to tell the operating system it is a package). To the user it
looks like a single file, unless they choose to show the package
contents (via a contextual menu).

Inside the package, there is a well defined folder structure, which
varies depending on the type of package. For example, in an application
there is a Contents folder, and inside that there is an OS-specific
folder (MacOS) which contains the code, and a Resources folder which
contains a bunch of files, usually subdivided into multiple language
subfolders. Individual items which were stored as resources in classic
Mac OS applications are now located in .nib files which collect together
several related items (e.g. all the strings are in one file).

Tools and operating systems which are unaware of packages will just
treat the whole thing as a folder, and the system relies mostly on file
extensions (.app) to ensure the package is treated correctly.

Apple have now started using packages for documents as well as
applications, e.g. iWork (Keynote, Pages and Numbers) store their
documents as packages, though this isn't much use for interacting with
other software since the file formats are undocumented. It looks like
they are using XML for the document itself, which is compressed (with
gz), and the package contains separate files for the thumbnail icon,
QuickLook preview and an information file to describe the package. If
the document includes resources such as embedded graphics they might be
stored separately from the XML file which describes the document
structure.

The file type and creator mechanism is still used, but it is
supplemented by better support for file extensions, so applications can
use either or both methods for their documents, and the loss of
Mac-specific metadata (file type and creator) due to a trip through
another operating system is usually not a problem as long as the file
extension is intact.

There are also system-wide mechanisms for easily associating all
documents of a particular combination of type, creator and extension to
be opened with an application chosen by the user, and individual
documents can be set to open with different applications. This is
handled by a user-specific database maintained by the system, not by
modifying the individual files in any way.

With Mac OS X 10.5, the Finder Info (including filetype and creator) is
now one of several "extended attributes" which can be attached to a file
and are visible with Unix-layer tools such as 'ls'. Other parts of the
system can add extended attributes to files. For example, the Time
Machine backup mechanism supports an extended attribute to mark files or
folders which are not to be backed up.

Most of the extended attributes are implemented using named forks
(except for some which are handled specially and already have support in
the directory, such as Finder Info). Looking at an old application, I
see it has extended attributes called "com.apple.FinderInfo" and
"com.apple.ResourceFork".

Incidentally, the Mac uses AppleDouble (version 2) to store Mac files on
foreign file systems. If you see Mac-created files with '._xxx' names,
they are the AppleDouble component of the file called 'xxx', which
includes the resource fork, Finder information, etc. See RFC 1740 for
details of AppleSingle and AppleDouble.

-- 
David Empson
dempson@actrix.gen.nz