views:

420

answers:

1

A question similar to Locating bundles by identifier, but different problem:

I have several applications that need to locate each other's bundles by their ID. That always works well, unless I do a completely fresh install of all my applications. In many cases it's sufficient to point the finder to the install location for the bundle locations to be known, but sometimes even that's not enough; I have to run the application first before it's bundle ID can be used to find the path. I should mention that I am using an installer that copies the applications to the /Applications/, so the finder never opens when I install the apps.

It appears that when an application bundle is newly installed, it takes the system some time before some internal registry is updated that maps the bundle ID to the bundle location. What I would like to know is:

  1. where are these mappings maintained and
  2. how can I force the system/file manager/workspace (?) to update the map
+2  A: 

The mappings are maintained in the Launch Services database. I don't where this is stored, but the exact location is irrelevant, as there are better ways of achieving your goal.

You can manually update the Launch Services database in a number of ways, but personally, I think doing it programmatically would be easier, especially in your situation. In that case, you would utilize the Launch Services API—specifically, I'd look into using LSRegisterURL(), since that seems to achieve what you want to do.

Take a look at the Launch Services documentation for more information about registering applications in the database and how this all works in general.

htw
Thanks for the link to the Launch Services documentation. I DID read large parts of this documentation before, but apparently missed that paragraph. I was hoping for a simpler solution than using LSRegisterURL(), like running a snippet of AppleScript or something, but this is close enough so I'll accept it as answer. Thanks.
Thomas Jung
There is a tool called "lsregister" buried somewhere deep in the Launch Services framework that you can run as an alternative, but I'm not sure if that's simpler.
htw
htw: I think he wants to do this from an installer post-flight script. In that case, running an AppleScript would be simpler. Also, lsregister is only obliquely documented, so I wouldn't rely on it existing.
Peter Hosey