Everything Else
Collection Repair for Damaged Files

In some cases, a collection is damaged to the point that none of the Helix applications are able to open the file. This does not necessarily mean that the collection is badly damaged; it could simply mean there is something ‘fundamental’ wrong with the file, and Helix will not proceed out of caution.

In these cases, we encourage you to contact us for assistance. Unless your collection has suffered catastrophic failure due to hard disk malfunction or other issue of that magnitude, recovery is always an option.

While there are no guarantees, our average repair times have been trimmed to less than one day. Even seriously damaged collection can typically be handled in a day or two.

Damage From a Lost Resource Fork

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. (All Classic applications and most files contained a resource fork prior to Mac OS X.) Resources are managed by the OS itself, making it much easier (and faster) for the program to manage certain types of data.

Unfortunately, Apple has moved away from this ‘multi-fork’ concept and changed over to ‘packages’ which are really folders disguised as a single file.

Historically, the ‘Type and Creator’ codes that identify a type of file and which application it goes with were stored in the resource fork. That this fork is being phased out is why macOS files require (or expect) a file extension (.app, .pdf, etc.) as part of the name. Remove the ‘.jpg’ from an image’s filename and you will most likely discover that it can no longer be opened by double clicking on it.

In addition to the type and creator information, Helix collections store extremely 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.

Detecting a Lost Resource Fork

The typical appearance of a Helix file (or any file for that matter) that has had its resource fork stripped away is a generic ‘unix executable’ icon. You can add Helix’s extention (.heap) to such a file and its icon will change to appear as a Helix collection, and you can even double click it to launch Helix, but that will not magically recreate the resource fork, so this is only of use if the resource file is still intact, and the generic icon is due to some other issue in the Finder.

Unfortunately, Helix does not provide an unambiguous message when a collection’s resource fork has been stripped away. 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 (in Helix 6.1 and earlier) provided 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.

How a Resource Fork Gets Lost: The Transport Problem

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 macOS 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.)

How a Resource Fork Gets Lost: The “Cloud” Problem

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 macOS 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.)

How a Resource Fork Gets Lost: The Disk Format Problem

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:

  1. 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.
  2. 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 macOS 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.

Although the newer FAT32 format do preserve the resource fork, there are other issues related to FAT32 formatting (see also here) that may contribute to collection corruption. Our advice is to not use FAT32, but if you must, test carefully before trusting your collections to a FAT32 volume.)

How a Resource Fork Gets Lost: The Early macOS Problem

macOS is, at the core, a Unix operating system. Unix does not (to our knowledge) understand the concept of a resource fork either. macOS has a built in Create Archive function that uses Unix routines to create a .zip archive file.

Unfortunately, prior to macOS 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 macOS 10.4, and the built-in “Creating Archive” function (renamed ‘Compress’ in macOS 10.6) works correctly. If you are running macOS 10.3 or earlier, you should use a third party application such as Stuffit to create an archive of your Helix collection.

Recovery Options

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.

Repair Policies

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.