Re: what are .sdk archives?
- From: dempson@xxxxxxxxxxxxx (David Empson)
- Date: Wed, 2 Jan 2008 14:49:22 +1300
Gregory Weston <uce@xxxxxxxxxx> wrote:
In article <0Zbdj.199$sE5.47@trndny05>,
"Charlie" <charlieDOTd@xxxxxxxxxxxxx> wrote:
"Gregory Weston" <uce@xxxxxxxxxx> wrote in message
news:uce-374A13.08265128122007@xxxxxxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx
.
- References:
- Re: what are .sdk archives?
- From: Gregory Weston
- Re: what are .sdk archives?
- Prev by Date: Re: Original Apple IIc serial inaccuracy (?)
- Next by Date: Re: ProDos Patch
- Previous by thread: Re: what are .sdk archives?
- Next by thread: Re: what are .sdk archives?
- Index(es):
Relevant Pages
|
