What creates com.apple.LaunchServices.plist?

The com.apple.LaunchServices.plist file has little, if anything, to do with Safari.

Launch Services is the part of OS X that manages document-to-application bindings. It keeps track of what applications are present on your system and what documents they're capable of opening. The Finder uses Launch Services to gather that default information which is stored in the Launch Services database cache file.

If you select a PDF in the Finder, open the Get Info window, and in the Open with section, choose to open it in a non-default application, initially that preference is saved on a per-file basis. If you click the "Change All" button, however, that global preference is saved in the com.apple.LaunchServices.plist file.

While Safari may use Launch Services during and after downloading files, there's not too much else where it'd use it that I'm aware of (for example, when loading web pages, etc.).

Hope this helps....

Dual 2.7 GHz PowerPC G5 w/ 2.5 GB RAM Mac OS X (10.4.3)

Hi, R C-R and Mark —

R C-R, I hope you don't mind my piggy-backing here — to explore this in a bit more depth. I've wondered about some of the same things that I think you are.

Mark, between what you've said here and in your post in another thread today, you've cleared up several things that have confused me about Launch Services. Much appreciated.

I wonder if you'd help to clear up something else, too. My question(s) will make more sense after I add a little detail to the discussion about registering applications.

Launch Services Concepts and Tasks does a good job of explaining most of the details of the API, imo. As good or better than many ADC docs, anyway (such as the much less layperson-accessible Launch Services Reference)...

How Does Launch Services Register Applications? In the section "Registering Applications," the former ref. explains 3 ways that applications may be registered
"to make them known to Launch Services and copy their document binding and other information into its database." —

" • A built-in background tool, run whenever the system is booted or a new user logs in, automatically searches the Applications folders in the system, network, local, and user domains and registers any new applications it finds there. (This operation is analogous to “rebuilding the desktop” in earlier versions of Mac OS.)

• The Finder automatically registers all applications as it becomes aware of them, such as when they are dragged onto the user’s disk or when the user navigates to a folder containing them.

• When the user attempts to open a document for which no preferred application can be found in the Launch Services database, the Finder presents a dialog asking the user to select an application with which to open the document. It then registers that application before launching it."

My question(s): Where is the Launch Services Database? and How does it interact with the com.apple.LaunchServices.plist preferences file?

From looking at the Terminal command — and in your "Launch Services Database Rebuild" AppleScript — I'm guessing the answers may have something to do with /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ — and perhaps with the processes lsregister &/or lssave in the /Support/ folder...?
Are any user caches involved in storing "user-specified binding" data??
Thanks!
Since it's snowing here in SLC, I'll wish you both the warmest of holidays!
Dean
I edited this message... But not enough!

The names of and paths to the Launch Services database files have varied from one release of OS X to the next.

In Tiger, there's essentially a single cache/database file for each user:

/Library/Caches/com.apple.LaunchServices-014###.csstore

### is the unique numerical User ID assigned to each user on the system: root = 0, first user = 501, second user = 502, etc.

For Panther, the file was:

/Library/Caches/com.apple.LaunchServices.6B.csstore

(It also included a way of creating one for each user, but I don't recall what the details were).

"lsregister" is what runs at startup and login to gather the information. The Finder itself keeps track of any new information by caching it in RAM, and then periodically I believe it calls the "lssave" tool to save the information to disk.

The Launch Services cache file is what's used to determine what application will open what document by default. When you change the setting for one file, at first the information is stored in the file itself. See this thread for more info on that. That thread also explains what clicking the Change All button will do.

Hope this helps...


Dual 2.7 GHz PowerPC G5 w/ 2.5 GB RAM Mac OS X (10.4.3)

Thanks grandly, Mark!

{Btw, what tool created the 2nd / 3rd windows in the illustration you used in the cited post?}

Hi, R C-R (and Mark, et.al.) —

Since this has been puzzling me, I also did a little digging by opening a copy of my com.apple.LaunchServices.plist file with Property List Editor. (I actually did what's described below before posting on Tuesday.) Most of what I found may simply confirm your inquiry — but perhaps something will be enlightening...

I expected that my com.apple.LaunchServices.plist file would be pretty simple, because i haven't done much/any changing of things since I had to do an Archive & Install in September. My preferences file defined only 12 LSHandler Dictionaries (0 through 11) that apparently "service" only Safari, TextEdit, iTunes, and QuickTime. Although I'm sure your .plist preferences [were] different (e.g., I haven't launched iCal — which may explain that difference), my point here is that, like you, I use many more applications than that. So I wondered — why does this .plist file include and exclude what it does?
A Test to Find Out. I ran a ~limited test by using "Get Info" to "Change All" files with .pdf extensions temporarily to open them using Adobe Reader instead of Preview, checking the modification dates/times of the preferences, caches (com.apple.LaunchServices-0140.csstore and com.apple.LaunchServices-014uid.csstore from /Library/Caches/), and frameworks files/folder related to Launch Services before and after. Just as Mark said, only the com.apple.LaunchServices.plist preferences file was apparently modified to reflect the change. After restarting and changing back to Preview, I again used Property List Editor to view a copy of the revised com.apple.LaunchServices.plist. An additional, new LSHandler Dictionary (12) had been created — defining two strings (LSHandlerContentType and LSHandlerRoleAll) with values of com.adobe.pdf and com.apple.preview, respectively.
So, with Mark's and your help, this is starting to make more sense to me: apparently the com.apple.LaunchServices.plist file was only updated to reflect a "user-specified binding" — and the specific change to the .plist is quite succinct. That modification apparently refers to the appropriate applications' preferences for details.
Does this make sense?
Warmly,
Dean

Hi, R C-R —

Sorry I wasn't clear.

By " [a]fter restarting and changing back to Preview ," I meant:
• I did a normal restart, to confirm that no further modifications were made by doing so
• I selected a file with the .pdf extension — at that point showing the custom icon resource associated with Adobe Reader, then did ⌘-I and "Change all" again, back to Preview — i.e., changing the binding back to its original assignment
• I checked for changed modification dates/times again, to confirm this — and, as before, opened the modified com.apple.LaunchServices.plist file with Property List Editor.
I reported the changes in my last message. Given your query, I just checked to confirm that those were the only LSHandlers changers — they were. (I saved everything.) The corresponding (and only) changes within the property list dump were:

<dict>
<key>LSHandlerContentType</key>
<string>com.adobe.pdf</string>
<key>LSHandlerRoleAll</key>
<string>com.apple.preview</string>
</dict>

That's the extent of my grasp of things at the moment. Perhaps Mark or someone else can help to explain why this was the case instead of a "third, boolean dictionary entry (LSHandlerIgnoreCreator) being set to 'yes,'" as you expected.
I'm also not sure why this latter issue isn't explained — or at least identified — in the Property List Key Reference section of Mac OS X Runtime Configuration Guidelines. Perhaps that's the wrong reference. I'll have to look around...
Hth,
Dean