Re: Forked Files

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

Robert Flossmann <robert.flossmann@freenet.de> wrote:

> could someone please help me understand the concept of forked files, as
> I keep running into these when toying around with my Apple IIe/IIGS and
> Macs. I understand that there are two parts to an Apple file, the data
> fork and the resource fork. Now for some questions:
> 
> *     Are the two forks stored in a contiguous manner (1 file) or as two
> seperate files?

They are effectively two separate files, but they are tied together by a
single directory entry.  When an application deals with the file, it has
to treat the resource and data fork independently.  For example, to copy
a file with resource and data forks requires opening the source and
destination data fork, reading from the source and writing to the
destination, closing the forks, then repeating the whole process for the
resource forks.

Adding data to either fork does not require "inserting" data into the
middle of a single larger file.  At this level, the file system treats
them as completely separate files (which just happen to share a
directory entry).

The precise details vary depending on which file system you are talking
about.

In the case of an HFS volume, the directory entry contains fields which
allow the operating system to locate both forks.  Resource forks were
designed into the file system from day one.

For a ProDOS volume, Apple had to invent a new way of storing files with
resource forks, since the original design of the file system didn't
support the concept of forks.

A standard file on a ProDOS volume is stored as a series of data blocks
with zero, one or two levels of index blocks to tie all the data blocks
together.  The directory entry points to the highest level index block,
and a "storage type" field tells the operating system how many index
levels are used.

In order to allow a file to have a resource fork, Apple defined a new
"extended" storage type which adds an "extended key block".  The
directory refers to the extended key block, which contains
mini-directory entries to define the data and resource forks, plus extra
information such as the Macintosh file type and creator.  The data and
resource forks are structured like normal files beyond this point, with
zero, one or two levels of index blocks, and a storage type field in the
extended key block is used to identify the structure of the fork.

The problem is that ProDOS-8 was never updated to support the "extended"
storage type, and it will reject any attempt to open one of these files,
since it has no idea how to access any of the data contained in the
file.

On foreign file system such as FAT (MS-DOS), the Mac implements resource
forks by creating extra files in an invisible folder called
RESOURCE.FRK.  The data fork remains the "normal" file as far as the PC
is concerned.

For example, if you had a text file with a resource fork called
"README.TXT" which was stored in a subdirectory called "SUB" on a PC
floppy, the directory structure would look like this:

A:\
    README.TXT                  (data fork)
    RESOURCE.FRK\               (invisible directory)
        README.TXT              (resource fork and directory info)

> *     What does the data and resource forks contain respectively for, say,
> an application, a text file, a graphics file?

As far as the file system is concerned, there is no difference between a
data fork and a resource fork, except for the offset into the directory
structure (or extended key block) to locate it.

It is the operating system and toolbox which imposes meaning on the
content of the forks.

Both the Macintosh and IIgs have a "Resource Manager" toolset, which
support the use of the resource fork as a limited capacity database.
The resource fork may contain a large number of individual resources,
each of which has a specified resource type and an identification
number, with an optional name.  (The names are an inherent part of the
resource on the Mac, but they are a tacked-on feature for the IIgs,
actually stored in a separate resource.)

While the two implementations have similar purposes, the details are
quite different, and the internal structure of a Mac and IIgs resource
fork are completely incompatible with each other.

This means that you cannot use the Mac's Resource Manager to access data
in a IIgs resource fork, and vice versa.  Any software on the "wrong"
platform has to write its own implementation of the other platform's
Resource Manager.  A good example of this is Pointless, which runs on
the IIgs but which uses Mac TrueType fonts, which have a Mac-style
resource fork.

(Note that these differences don't affect the copying of a Mac file on a
IIgs, or a IIgs file on a Mac.   Copying a file doesn't involve the
Resource Manager: it just treats the fork as a nondescript sequence of
bytes, so it doesn't matter how the data within the fork is organised.)

On the Mac, resource types are a four character string (effectively a
32-bit integer), and resource ID numbers are a 16-bit integer.

On the IIgs, resource types are a 16-bit integer and resource ID numbers
are a 32-bit integer.

To get to your question:

As originally used on the Mac, the data fork was the place where the
simple data was to be stored, with the resource fork used to augment the
data or contain information about the data.

For example, with a SimpleText document (or any other text file), the
data fork contains the actual text of the document, while the resource
fork contains style information, embedded graphics, and the page setup
for printing.

Graphics files generally have the graphics data in the data fork and
additional nonessential information such as icons and page setup in the
resource fork.  There may be special cases, e.g. some Mac PICT files
might contain the picture data in resources.

QuickTime movies are an interesting case: the actual data referenced by
the movie must be in the data fork, but the control structures which
contain information about the movie, its track structure, data format,
etc. may be in either the data fork or the resource fork.  Sticking to
the data fork is recommended for movies which are to be transferred over
a network or used on a PC.

Applications vary:

For a Macintosh 68K application, the data fork is unused (or it may be
used by the application for a special purpose).  The resource fork
contains a mixture of application code (in 'CODE' resources) and a
variety of other resource types used by the application to contain
elements of its user interface and other data it may require.

For a Macintosh PowerPC application, the data fork usually contains the
code (it may also contain application-defined information), while the
resource fork contains the same collection of resources related to the
user interface.

A "fat" application on the Mac has both PowerPC code (in the data fork)
and 68K code (in the resource fork), as well as all the other resources
(which can be used by both the 68K and PowerPC versions of the
application).

Things have a got a little more complicated since MacOS 9 and X
surfaced.  I don't really want to go into the details here.  Suffice it
to say that with Mac OS X, Apple is encouraging movement away from the
use of resource forks.

On the Apple II, the resource fork is only supported on the IIgs, and
then only under GS/OS, and _then_ only if you are running System 5.0 or
later.  Resource fork support was only available in limited form for
System 4.0 (the initial release of GS/OS), and the IIgs Resource Manager
wasn't introduced until 5.0.

The structure of a IIgs application was defined long before this, so a
IIgs application must use the data fork for its code.  The use of the
resource fork is optional.  The application may use it in the same
manner as a PowerPC application on the Mac, i.e. for storage of
arbitrary items of data, particularly those relating to the user
interface of the application.

The IIgs also supports the concept of a code resource, and the best
example of this is HyperCard IIgs, which uses code resources for
external commands and functions (just like on the Mac).

> *     What is lost on transfer of, say, a text file to a Windoze PC?

If you are copying from a Mac directly to a PC disk, you lose nothing,
because it will create invisible files and folders as necessary.  If the
data fork file (the "normal" file) is then copied elsewhere on the PC
without also copying the associated file in the RESOURCE.FRK
subdirectory, it will be detached from the resource fork.

Copying via a file transfer protocol of some kind will cause the
resource fork to be lost (if the PC is to be able to read the data fork
without seeing any extra garbage) unless the file is encapsulated in a
special format like MacBinary or BinHex which allows both forks and the
Macintosh directory information to be retained, or if the transfer
protocol supports forks (e.g. AppleShare).

The outcome of losing the resource fork varies depending on the file.
In the case of a text file, you should retain the plain text but lose
all style information.  For a graphics file, the image should be intact.
For a Mac application, the loss of the resource fork is fatal (except
for Mac OS X applications which avoid the use of the resource fork).

Another point to keep in mind is the file type and creator information,
which varies in importance depending on the file in question.  It is
absolutely essential that this be retained for a Mac application, pretty
important for a IIgs application (easier to reconstruct), and usually
unimportant for a text file.

The file type and creator (file type and auxiliary type for the Apple
II) are stored in the directory entry for the file.  Other file systems
have no concept of type and creator, so what usually happens is the
Mac/II-specific directory information gets saved along with the resource
fork (e.g. in an AppleDouble file, as typically sent by a Mac when using
MIME-encoded E-Mail), though it isn't actually part of the resource
fork.

Here endeth the lesson for today.  :-)