Iron Coder 7 is coming up, and Jonathan Wight just announced that the top prize will be an iPod Touch! In other news the contest will run over the course of a week this time around, instead of the usual 48 hours.
I am going to need something to develop my iPhone/iPod applications on pretty soon.
Leopard brings so many little features that I am having a hard time devoting time to playing with many of them. One of the best-designed of these features is called Spaces, and supplies a familiar feature to anybody who has used virtual desktops on any platform. The basic gist is that you can switch between “virtual monitors”, each of which holds a different set of running applications.
In many ways Leopard is all about the animation, and it’s used very effectively in Spaces, where switching between virtual desktops comes with an instantaneous (even on my PowerMac G5) slide animation, as if your monitor was connected to a camera that is suddenly picked up and swept over to land on some other area of desktop real estate. Pretty nifty.
But I haven’t really gotten into the habit of using this feature, and therefore didn’t notice one way in which it sort of behaves awkwardly with MarsEdit. Fortunately, one of my customers noticed the problem and dropped me a line. I did some research and discovered what I believe to be the following truth:
Dismissing a modal sheet in an application causes Spaces to awkwardly zoom that application’s space back into vision.
This is particularly awkward with MarsEdit because while a post is being sent to the server, the post window puts up a sheet conveying that information to the user. If you send a post and immediately switch spaces, then when MarsEdit finishes publishing, it Spaces will zoom you right back to MarsEdit’s space!
I filed a bug, and Erik filed one as well. Hopefully Apple will agree it’s egregious and fix it in an update.
If you, like me, have essentially kept a single keychain from the dawn of time, there’s a feature in the Keychain Access application you need to know about: “Keychain First Aid.”
You find it under the Keychain Access menu, just below Preferences. Whenever I see anything unusual happening with my keychain, I try to remember to hop into Keychain Access and re-run this. Putting aside the question of why my keychain is allowed to get so routinely screwed up that it requires “first aid,” let me say that I appreciate this repair functionality because it generally solves problems quickly and effectively.
Starting with Leopard 10.5, I saw some really strange behavior. Sometimes keychain seemed to contain my web passwords, for instance, and sometimes not. I hopped into Keychain Access and did the first first aid dance. Whoah, mega-red warnings. The first thing that stood out for me is that I somehow had come into a situation where I have two keychains named “daniel”, each configured as part of my keychain search list.
It turns out that in my ~/Library/Keychains folder there exist two keychain files, but one of them contains the “.keychain” extension, while the other does not. I suspect what happened is at some point (in 10.5?) Apple decided to require that keychains have this file extension, so they quietly upgraded my existing keychain without removing the original. This explains my feeling that keychain was mysteriously showing duplicates for many keychain items!
What’s really mysterious though is the way it continued to access both keychains, apparently sometimes choosing from one and sometimes from the other. It made me wonder which was most up to date, but I couldn’t really guess since each had recent modified dates. I picked one and moved the other to the side as a “backup.” Now I’ve got a single “daniel” keychain, and everything should be fine. If I find myself missing a password, I’ll have to rename the backup to “bogus” or something, import it to Keychain Access, and search it for the password to copy over into the one-true-keychain.
(Note: Unless you’re a really old-timer like me, chances are your “daniel” keychain is called “login”. It’s probably wisest to keep it this way, because Apple’s First Aid also seems to get upset sometimes if there isn’t a keychain in the search list with that name. I stubbornly refuse to change, for now.)
I’ve been testing Leopard for many months, but not until updating to the final version did I get bit by a strange side-effect of a new default behavior in 10.5, relating to Access Control Lists (ACLs).
My habit for migrating to new testing releases of Leopard, and ultimately to the final release, has been to keep my old home directory, but to point my new operating system at it by defining a custom home directory location. This works great, especially since I can install lots of handy things like system preference panes once in my home directory and have them at my disposal forever without reinstalling them.
I also have a habit of keeping a lot of my testing resources for MarsEdit and other products set up in my home directory. As soon as I upgrade to a new system, I fine-tune a couple settings and I’m off and running again with my “usual development environment.”
As you might imagine, one of the important resources to testing MarsEdit is a local Apache web server configured to serve a variety of test blogs. It makes it a lot easier for me to test when users report a problem against a particular system, if I can just hook up to my own private replica. I don’t even need to have an internet connection, because the blog server and client are all running right on my Mac. It’s pretty super!
I noticed after upgrading to the final release of Leopard that none of my test servers were working as expected. Navigating to a test blog via the browser yielded a mysterious permissions error. What on earth could it be? Apache worked perfectly before, and now is failing with a cryptic error. The Apache error log just repeats this mysterious failure:
Symbolic link not allowed or link target not accessible: /Library/WebServer/Documents
I’ll admit this message is not completely out of left field, as I do use a symbolic link to identify my web server folder. I run a script after updating the OS, to put many common facilities “back into order.” Among other things it wipes out the usual directory for “Web Sharing” and replaces it with a link to my testing stuff, stored inside the Documents folder of my home directory. This works brilliantly because I’m assured the stuff I care about is safely stowed in my home directory, and changes I make will get saved even if I wipe out the OS.
So why is this link suddenly failing on Leopard? It’s perplexing. It worked in Tiger, and it worked in all of my testing up until the final release of Leopard. I thought the link must be bad. No. Perhaps I’ve screwed up my Apache config? No, it’s exactly the same. I don’t know if I should be angry or embarrassed about the fact that it took me 2 hours of debugging to figure out the root cause of the problem, but I’ll spare you all the gory details and cut to the chase.
Leopard 10.5 seems to have gone out of its way to alter the permissions of key directories in my home directory, adding an explicit “can’t delete” rule to Documents and several other of the special folders. I spotted a clue when I did an ls from the terminal, and noticed an extra “+” after the permissions, which I learned means it has an Access Control List associated with it. I then learned about the “-e” option to examine the ACL settings explicitly, for example “ls -led Documents” yields:
drwxr-xr-x+ 103 daniel 501 3502 Oct 26 17:23 Documents 0: group:everyone deny delete
See that line? It means nobody can delete the folder. The worst thing? This particular ACL setting makes no visible impact on the permissions settings that are editable via the Finder. It just says “Everyone: Read Only.” Apparently the rule to disallow deletion is not supported by the UI (except to the extent that if you try to trash one of these altered folders, you will be refused). So if you don’t figure out how to use ls with the appropriate flags, you’ll never notice the change. And if you don’t learn how to use “chmod” with the appropriate flags, you’ll also never be able to remove the item from the ACL.
I removed the ACL rule from the Documents folder (chmod -N Documents), so that its permissions matched “the good old days.” I went to reload my server in the browser and voila, problem solved. I’m still not sure exactly why this caused a problem, but that’s the least of my concerns. The fact that it was caused by Leopard changing the permissions of directories in my home directory makes me a teeny bit annoyed. I like to think of the items in my home directory as belonging to me — as being somewhat sacred and under my control.
Ah, well. I suppose these special folders have always carried signs of Apple’s ownership. After all, they get magical custom icons, so maybe I should choose another less territorial area for my important files. But this does make a sort of tangential example of how things can go wrong because of the most subtle of changes. When we developers whine and moan about not having access to the release OS in time to test, this is exactly the kind of thing we are worried about. We never really know what we’re dealing with until the final release is before us, so we’re naturally nervous until we can sit down and test it.
Fortunately in this case the issue doesn’t affect any of my products, so far as I can tell. It only ground my testing and development environment to a halt for a few hours. But for other developers, who knows? If you’re running into mysteriously permissions-related problems, it might be worth a look at those access control lists.
The Red Sweater Blog features updates about our apps and articles about related topics.
