Until very 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.

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 are, the records are stored, the indexes are found… all of these and more are stored in the resource fork.

If the resource fork of a collection is separated from the file, the collection can no longer be opened with Helix. In fact, Helix will not even recognize it as a collection at all. Typically the OS X Finder puts a Terminal icon with the words ‘exec’ on these files.

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.

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

Even though FAT16 has been superseded by newer, more flexible formats, many vendors still use FAT16, probably because it is the ‘most compatible’ format and they probably get fewer “it doesn’t work” returns that way. Our experience is that the majority of flash drives (aka: thumb drives) are FAT16 formatted. With those you can use Apple’s Disk Utility program to reformat them using an Apple-safe format.

Once you have copied a Helix collection onto one of these volumes, the resource fork is gone. And once it is gone, there is no way to recover it. It simply does not exist (except on the original, if you haven’t deleted that).

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

Fortunately, Apple fixed this issue in OS X 10.4, and the built-in function for creating an archive (renamed as ‘compressing’ in OS X 10.6) works fine. But if you are running OS X 10.3 or earlier, you should use a third party applications such as Stuffit to create an archive of your Helix collection.

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.