|TS1240: Mac OS 10.3.2 and Helix Startup Conflict|
After updating to macOS 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 macOS 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 added a “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 macOS 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.”
Unchecking the “Create a local copy of your iDisk” option resolves the error. Alternatively, you can edit the HRFL resource to forcing Helix to use a specific volume for its temporary files.
A similar issue was actually observed while trying to track down the bug: Running on a PowerMac G5, Helix was saving its temporary files on the mounted volume of a PowerBook. This seems to indicate that under 10.3.2, Helix is no longer able to discern whether a mounted volume is local or on a server.
This bug is resolved in Helix 6.2, where the temporary files are explicitly stored in the user’s ~/Library/Caches/TemporaryItems/ folder, unless there is an override via the HxShadowFilePaths preference.