In yesterday’s article, I listed the main tasks of Launch Services, and explored how it appears to perform just one of them. Accomplishing the others,

• launching apps from other apps,
• opening documents or URLs in other apps,
• identifying the default app with which to open a document or URL,
• maintaining lists of document and URL types which an app can open,
• providing ancillary information about files and URLs, such as an associated icon,

requires a database which tracks apps and their capabilities, and document and URL types and how they should be represented.

Way back in classic MacOS, the Finder’s desktop databases maintained that information, and it was not uncommon to have to rebuild them periodically to resynchronise document and app icons.

In early versions of Mac OS X, the database was kept in two files, ~/Library/Preferences/LSApplications and LSClaimedTypes, but those days are also long since gone. macOS now hides the database, and the only way of modifying it is through the undocumented command tool lsregister, which is not even stored in one of the usual locations for command tools.

The wrong app

The most common problem which occurs with Launch Services is that they misassociate a document type with an app. By default, text documents with the extensions .txt, .text, and their variations, are set to be opened by TextEdit. You might have changed that, so that they will open in your favourite text editor. Then one day, you try opening a text document directly – for which Launch Services determines the app to use – and the wrong app starts up.

As an isolated occurrence, the solution is simple: select that document in the Finder, and open its Get Info dialog (in the File menu, or Command-I shortcut).

There you can change the app used to open that document, and then click on the Change All… button to apply that to all other documents of that type. Before doing so, check that the Kind shown at the very top is correct – the document might have a misleading filename extension which has confused Launch Services.

That should fix the problem. If it appears more general, affecting other types of document, or the app associated with a document type keeps changing, or changes back to the wrong app, then your Launch Services database may be frazzled and needs to be rebuilt.

The wrong information

There is no simple way to rebuild your Launch Services database, unless you have a utility such as OnyX which includes this as a feature. Restarting in Safe mode (with the Shift key held) flushes quite a few caches, but does not touch the Launch Services database. Even if someone were to tell you where to find the files, you cannot just trash them.

The tool which maintains the Launch Services database is lsregister, which is conveniently tucked away in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support. It has no man page, but typing
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -h
in Terminal will return its usage information.

To reset the Launch Services database, you should use its -kill option. You want this to be applied through a recursive directory scan, so also need the -r option. It’s wise to watch its progress in verbose mode (-v option), and you need to specify the domains to which this will apply.

Generally, the command advised is
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain u -domain s -domain l -v
to which some add the option to scan default locations to seed the database, -seed.

There are some issues with that command as given. It covers three domains – system, local, and user – which makes it very extensive, perhaps more so than is required. It also uses a different syntax from that given for the command in Sierra 10.12.6. Instead, I suggest that you try in the first instance
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -apps u

That should do the trick. If it doesn’t, then widen the domains with
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -apps u,s,l
and finally try
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -all u,s,l
which should wipe everything from the database.

It is also not impossible that you find you have to use the older syntax with
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -domain u

The snag with resetting the Launch Services database is that your Mac will take time to gradually rebuild it, during which its functions will run much slower. After a while, though, it will have been rebuilt, and the right app should be associated with each document type.

Apple does not tell us which service maintains the Launch Services database, but I have a strong suspicion that it is lsd, or a close relative. It is not that important, as your only controls are in the lsregister command tool, which is limited in its powers.