Robert Flossmann 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. :-)