Copying Cocoa apps from OS 9 to OS X fails: the explanation

Paul Mix replies: "It is possible that the execute permissions of the application (both the bundle root and the actual executable) were not copied properly during the transfer."

Rick Roe concurs, adding more details: "The reason this doesn't work in some cases is that the binary executable inside a bundled OS X app needs to have its Unix 'execute' permission preserved. If you don't have execute permission for Foo.app/Contents/MacOS/Foo, the app won't launch when double-clicked. Also, apps that contain frameworks (such as OmniWeb) need to have Unix symbolic links preserved.

When you copy a bundled app from one HFS Plus volume to another in OS 9, the extra HFS file info containing the Unix attributes is preserved (even though OS 9 doesn't do anything with it). However, other means of getting a bundled app from here to there don't work at the filesystem level - they just copy the information they 'know' is useful to Classic Mac OS software. Mac OS 9's version of AppleShare (and possibly any AFP client that doesn't support the 3.0 version of the protocol) does this, as do versions of StuffIt prior to 6.0.1 and other older archival utilities.

It's important to note that this problem isn't limited to Cocoa apps - bundled Cabon/MachO apps, frameworks, bundled MachO plugins, and Unix command-line tools would be affected as well.

Fixing a bundled app that's been broken by losing its Unix permissions isn't too hard, as all you need to do is restore execute permission to the executable, using the command line ("chmod x Foo.app/Contents/MacOS/Foo") or a utility such as Bare Bones' Super Get Info. (If it's a framework, or an app containing frameworks, you'd also need to restore the symbolic links. That's left as an exercise to the reader.)"