So, Apple added this cool little capability to the Launch Services API in Leopard: LSSharedFileListAddObserver will call your observer function whenever there are changes in a number of different file lists maintained by Launch Services. One of those lists is the “Recent Documents” list in the Apple Menu. “Great!” I thought, “I’ll roll this into Default Folder X to ensure that it doesn’t miss any recently used folders.” It’s a simple API – what could go wrong? As a long time developer, I should have known better – if you EVER say this (even if you never even say it out loud), you need to poke yourself with something sharp and realize that the consequences will probably hurt quite a bit more than that. “What could go wrong?” indeed.
So yes, here I am apologizing for not having poked myself after I used LSSharedFileListAddObserver without asking more questions – or at least without testing more. Here’s how Default Folder X ended up using 60% of some users’ CPUs while doing nothing useful:
- DFX added itself as an observer for kLSSharedFileListRecentDocumentItems.
- The observer function got called by Launch Services because the user double-clicked a document in the Finder.
- DFX looked at the list, took the most recent entry in it (the first one), asked Launch Services for the URL of the document, and added the folder enclosing that document to its Recent Folders list.
Pretty simple, right? Yeah, I thought so too. This was tested thoroughly on Snow Leopard and performed fine, and all my Leopard testers reported that it worked well for them too.
So what’s the problem then? Well, there’s this little “issue”… If a user has a Windows server mounted on the Desktop, things get a little more interesting. Normally, when Launch Services calls your observer function, it hands you the file list and you ask for a copy of the list. The list itself is just a series of ID’s and references – to see what’s in an entry, you have to call LSSharedFileListItemResolve(). And that’s where the interesting part happened. On Leopard, if the shared file list item lies on a Windows server, the act of calling LSSharedFileListItemResolve actually results in the item being changed, so your observer function gets called again the next time you hit your event loop. The result of this is that you get called over and over again if you naively use LSSharedFileListItemResolve to get more info about the items that Launch Services is handing you.
So – the warning: If you use LSSharedFileListAddObserver to watch the list of recent documents, keep a copy of the ID’s from the previous call and ONLY call LSSharedFileListItemResolve if there’s a new ID in the array. Otherwise do nothing, or work off cached information – otherwise you’ll end up in an infinite loop, sucking down lots of CPU time. And if you’re doing anything that interacts with the filesystem, make SURE you test with SMB shared volumes too.
