After updating to Mac OS X 10.3.2, a number of users report errors when trying to open Helix databases. Attemping to open a collection with RADE results in a "the database is damaged and can not be opened" error. Attempting to create a new collection with RADE, or to Visit a database with Client results in a "strange error code=22" error. Helix and Mac OS utility programs do not report any problems.

The problem stems from the "Create a local copy of your iDisk" option in OS X 10.3 (see System Preference -> .Mac -> iDisk). With this option turned on, the OS mirrors (exactly) the data stored on Apple's iDisk server, including disk permissions. These permissions do not allow Helix to create its recovery file.

Turn off the local copy of your iDisk or edit the HRFL resource to point to your local hard disk, forcing Helix to use a volume it can conduct proper I/O with.

After a late night of researching, we have the solution: We blame Apple. More exactly: .mac.

Mac OS 10.3 has this neat "Create a local copy of your iDisk" feature (see System Preference -> .Mac -> iDisk). This mirrors (exactly) what is on Apple's iDisk server, including disk permissions. The permissions say you can only write in certain folders - and not at all on the root directory of the iDisk.

A mounted iDisk (when you're not using a local copy of your iDisk) is a separate disk, so it makes sense for Helix to see it as such. However, because OS X 10.3 treats the local copy as a virtual disk, Helix see it as a legitimate place to put its recovery file.

The problem occurs when Helix gets to the point where it needs to create its recovery file. At this point, Helix goes looking for a disk to use and it mistakenly chooses the local copy of the iDisk. When Helix tries to create a copy of the file on the local copy of the iDisk, and it can't (permission denied). Helix then gives up and tells the user there's an error 22: "I/O error relating to the creation of the Helix recovery file."

(I actually had a similar issue tonight while trying to track down the bug - Helix on the G5 was saving temp files on the Powerbook (I know this because I heard disk activity coming from the Powerbook when I was creating a new collection on the G5). This seems to indicate that under 10.3.2, Helix is no longer able to discern whether a volume is local or on a server, which is another issue to watch out for. (Oddly enough, that worked, but the permissions are much less rigid on the powerbook than on the iDisk.)

As soon as I unchecked "Create a local copy of your iDisk" I was able to create a new collection.

So the solution is to either turn off the local copy of your iDisk, or edit the HRFL resource to point to your local hard disk, forcing Helix to use a volume it can conduct proper I/O with.

I don't know why this didn't show up sooner. I've been using Helix with 10.3 since it was released and haven't seen a problem. Something low level may have changed in the 10.3.2 update - I don't know. But it may explain why this isn't affecting more people.

Hope this helps,
helen and shasta