Sigh.

We've received a lot of complaints/emails/oddly worded love letters from users that have said APE just doesn't work at all (or some APE Module doesn't work at all). Until recently, we've had no idea the cause of these problems. Oddly, the number of people reporting the problem got much higher once APE 2.0 was released. Please, please remmeber that if someone is having a problem, the chances of them reporting it is nearly 90%. Whereas if someone is not having a problem, the chances of them reporting it is nigh 0%. I mean, why bother to email someone if everything is working A-OK, right? Luckily, some of these users had a console (/Applications/Utilities/Console) log containing some APE error messages, specifically, the error -43. Error -43 is fnfErr or File Not Found. Since the section of the APE code that wasn't running correctly uses a lot of BSD and CoreFoundation APIs, neither of which return usable errors like fnfErr this error could only be coming from one point in the code. In order for that error to be returned, the code path must hit an impossible case, or so I thought (I'm not the brightest cookie in the dryer). If that part of the code was hitting this error, then how could APE have even ran any code at all? I mean, this was being logged by aped but aped can't be launched if the APE framework cannot be found. Turns out that these few machines with the impossible case were the "key" to finding the issue.

If you look at the Anatomy of a Framework documentation McDealie you can see that most (if not all) Frameworks have symlinks in their root directory pointing to the actual folders in the current version of the framework (since frameworks can contain more than one binary incompatible version). According to the lstat documentation symlinks do not have their own permissions, owner, modes, or group. They take the permissions of the parent folder or the target item (depending on which documentation you read). Therefore, there was no need for the APE installer to create these symlinks with special permissions. However, turns out there's this happy little bug in Mac OS X 10.4.x in which the permissions of symlinks are actually respected and on these particular computers, there was no read access to the symlinks which means they couldn't be resolved which then meant APE wouldn't work at all.

You can easily confirm this bug for yourself if you so desire. Open the terminal (/Applications/Utilities/Terminal) and type:

cd ~/Desktop
umask 0777
ln -s textfile.txt symlink.txt
umask 022
echo "blah blah blah" > textfile.txt
ls -AFl *.txt

When you issue the last command, you'll notice an error that says ls: symlink.txt: Permission denied if you're on Mac OS X 10.4.x. If you're not on 10.4.x, it will correctly show it is a link to textfile.txt. The odd part about this is that double-clicking on the symlink in the Finder correctly opens the original file. Go figure, the Finder does what it's supposed to do.

Once a symlink is made, its permissions cannot be changed. Even if you try to use something like chmod, the changes will not stick. Mac OS X does not support things like lchmod (despite what the symlink documentation says). That means the only way to fix these broken symlinks is to destroy them and create them anew.

How to tell if you're affected by this bug.

If you have a non-working APE install and think this symlink bug might be the reason why you cannot use APE, there's a super quick and easy way to find out if your thought is based in reality. Open the terminal (/Applications/Utilities/Terminal) and type:

ls -AFl /Library/Frameworks/ApplicationEnhancer.framework/

If you are affected by the bug, then ls will list the permissions for the symlinks as lrwxr-x---. If you are not affected and APE is correctly installed, it will list them as lrwxr-xr-x (the 'l' means "symlink", a 'd' means "directory"). Notice how the last 3 characters are r-x in the working version and not ---? That means that people that are not the owner (root) or a member of the group owner (admin) can also read the symlinks. If the permissions are wrong, there's an easy fix.

So how do I fix it?

There's a simple fix to this. Simply download the APE 2.0.1b1 Installer, install it, and log out of Mac OS X. When you log back in, all should be well and APE should work again. You can confirm that the permissions on the symlinks are correct by using the above command in the above section in the above paragraph above what I just said. You do not need to install this if you are not having a problem with APE functioning. Please note that this installer does not change the version of APE listed in the Application Enhancer Preference pane.

If this does not fix APE not working and you are not logging in as root, then please email us along with the output of the above command showing the permissions on the symlinks. Remember, this bug only makes APE not work at all, it has no other side-effects. However, if your goldfish dies, you can go ahead and blame that one on APE.