Re: Forked Files

["Brendon Woirhaye" <bytre@nospam.com>]

Something to add - if you use a windows-based machine as a file server, you
CAN store files with resource forks only if you use an NTFS-formatted
partition.  FAT and FAT32 don't support multiple resource streams.

"David Empson" <dempson@actrix.gen.nz> wrote in message
1ewrree.122hqm8b74s90N%dempson@actrix.gen.nz">news:1ewrree.122hqm8b74s90N%dempson@actrix.gen.nz...
> 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.  :-)
>