Mac OS files can contain multiple forks. Most long-time Mac users have heard of the ‘resource fork’ and ‘data fork’ that go together to create complex files. (Virtually all applications contain a resource fork.) Resources are managed by the OS itself, making it much easier (and faster) for the program to manage certain types of data.
Helix collections store vital information in the resource fork. The ‘master maps’ that tell Helix where the icons, records, indexes, etc. are found within the collection are stored in the resource fork.
If the resource fork of a collection is separated from the file, those maps are lost and the collection can no longer be opened with Helix.
Unfortunately, Helix does not provide an unambiguous message when the resource fork is lost. Helix RADE, Engine or Server reports simply that the collection is “damaged and cannot be opened.” (This is a generic message that is also shown when other types of damage are found.) Helix Utility simply reports that the collection “could not be opened.”
Update Collection provides a slightly more exacting message, stating that the collection cannot be opened “because of a resource manager error.” The most reliable confirmation for this type of damage is to attempt open the collection with a resource editor, such as ResEdit, Resourcer, or Rezilla. Those applications warn you explicitly that the file has no resource fork.
In the modern ‘cloud’ era, support for the resource fork is spotty. Some internet-based storage services do not support the resource fork, so services such as Dropbox, iCloud, Google Cloud, Amazon S3, et. al. should be tested carefully before trusting them with your Helix collections. Also be sure to retest frequently, as these services are sometimes ‘upgraded’ without notification.
If you are using OS X 10.4 or later, you can protect yourself from this problem by creating a ‘.zip archive’ of your files before transferring them. Do this by selecting the collection and choosing the ‘Create Archive’ or ‘Compress…’ option from the File menu. (This command is also available when right-clicking on a collection icon.)
Early on, the Windows world had no concept equivalent to the resource fork. (For all we know, it still doesn’t.) Consequently, the original “FAT16” disk format would strip away the resource fork of a Mac file that was copied onto it.
Once you have copied a Helix collection onto a volume that uses the FAT16 format, the resource fork is gone. And once it is gone, there is no way to recover it. It simply does not exist in the copy. Of course, the original, if you haven’t deleted it, is still intact.
Even though FAT16 has been superseded by newer, more flexible formats, many flash drive and hard disk vendors still ship their products using the FAT16 format. You can check this by clicking on the drive’s icon on the desktop, choosing ‘Get Info’ and reading the ‘Format’ information in the Info window. If your drive is formatted in FAT16, here are two solutions:
- Use Apple’s Disk Utility program to reformat the drive using an Apple-safe format. For use in a Mac-only environment, we recommend Mac OS Extended.
- Create a .zip archive of your collection before transferring it to a FAT16 volume. Do this by selecting the collection and choosing the ‘Create Archive’ or ‘Compress…’ option from the File menu. This command is also available when right-clicking on a collection icon. Note: this option will not work if you are using OS X 10.3 or earlier.
Our general recommendation is to ‘zip’ your Helix collection before moving it from one disk to another. The zip format also compresses the file, reducing the transfer time, which is particularly beneficial for internet transfers.
(We’ve done a few experiments and it appears that the newer FAT32 format does preserve the resource fork. But test carefully before trusting your collections to a FAT32 volume.)
Sending a Helix collection (or any multi-fork file) over the internet is a near-certain way to lose the resource fork. This is particularly true when using services that are ‘platform neutral.’ You can not typically transfer a Helix collection via email (SMTP), FTP, HTTP, or any other Transfer Protocol. Those services will strip the resource fork away and the resulting file will be damaged.
If you are using OS X 10.4 or later, you can protect yourself from this problem by creating a ‘.zip archive’ of your files before transferring them. Do this by selecting the collection and choosing the ‘Create Archive’ or ‘Compress…’ option from the File menu. (This command is also available when right-clicking on a collection icon.)
OS X is, at the core, a Unix operating system. Unix does not (to our knowledge) understand the concept of a resource fork either. OS X has a built in Create Archive function that uses Unix routines to create a .zip archive file.
Unfortunately, prior to OS X 10.4, this routine ignores the resource fork, causing it to be left out of the archive file. This, naturally, makes the archive file useless. (There are ways around this in 10.3 and earlier, but they require that you use the Terminal application to create your archives.)
Apple has fixed this issue in OS X 10.4, and the built-in “Creating Archive” function (renamed ‘Compress’ in OS X 10.6) works correctly. If you are running OS X 10.3 or earlier, you should use a third party application such as Stuffit to create an archive of your Helix collection.
Until recently, we did not think was realistically possible to repair a collection once the resource fork had been stripped away. We are now able to repair collections damaged in this way.
There are two recovery options when a Helix collection has been stripped of its resource fork: Data Recovery and Resource Fork Reconstruction
Data Recovery: The first option is to attempt to recover the data from the file. This is complicated by the fact that, with the exception of text fields, data is not stored in a Helix collection as plain ASCII text. QSA ToolWorks does have tools that enable us to translate the stored data into readable data for most data types, but Picture and Document field types can not be recovered using this method. In addition, no structure — therefore no calculations made on the data — can be recovered this way. All that is recovered is the raw field data.
The main advantage of data recovery is that it typically costs less than a full collection reconstruction. The data is returned to you in tab delimited text files that you can import into an older (or newly built) copy of the collection. The main disadvantage is that some data types (Pictures and Documents) can not be recovered this way.
Collection Reconstruction: Since the resource fork stores the maps that link the structural elements (fields, abaci, etc.) together, reconstructing the resource fork means recovering the whole collection, structure and all.
The main advantage of collection reconstruction is that the entire collection is typically recovered: all abaci, views, etc. are restored and the collection can be used in Helix again. The main disadvantage is that the cost of reconstruction is typically higher than raw data recovery, as it takes more time.
Our Collection Repair Policies and Procedures page contains information on cost, turnaround time, along with a step-by-step guide for arranging a repair. Feel free to contact our technical support department to discuss which option is right for you.