RCDefaultApp FAQ

System Preferences looks in /System/Library/PreferencePanes, /Network/Library/PreferencePanes, (if you've set that up for your local network), /Library/PreferencePanes, and ~/Library/PreferencePanes (~ is short for your home folder) for the preference panes it displays. All of the Apple-supplied panes are in /System/Library/PreferencePanes, and third-party ones go in one of the other locations (depending on which set of users you want it visible for... for a single user at home, there's not much difference).

On Panther, it is easiest to just double-click RCDefaultApp.prefPane, and System Preferences will ask where it should be installed (including creating the folder if necessary). If you make it available to all users (i.e. install in /Library/PreferencePanes), you will need to enter an administrator password.

On Jaguar, RCDefaultApp.prefPane must be dragged to the appropriate folder. If a third-party preference pane has not previously been installed, the PreferencePanes folder may have to be created first.

Once installed, RCDefaultApp should show up in System Preferences.app in the bottom "Other" section with the name "Default Apps". The name will be different for languages other than English.

Drag RCDefaultApp.prefPane to the trash. Any changed LaunchServices settings remain changed, though "disabled" settings will no longer be disabled.

Each application has an Info.plist file that declares the known URL protocols, extensions, MIME types, and file types the application can handle. When an application gets registered with LaunchServices (typically by viewing the folder in Finder), LaunchServices keeps this information in a list. RCDefaultApp queries LaunchServices for this list, and in some cases looks in the Info.plist files directly. Therefore, the list represents what the installed applications support.

As of version 1.2, RCDefaultApp allows custom extensions, MIME types, and file types to be added. Due to the way that URL protocols are implemented, it is very unlikely that an application will support a protocol it has not declared, and trying to force it can often end up with Applescript timeouts and other odd behavior.

As mentioned in the README, "disabling" an entry actually assigns it to a dummy application contained within RCDefaultApp.prefPane called DoNothing.app. This application will launch for a few seconds in the background, and then exit. This is done because LaunchServices does not allow an entry to be truly disabled.

In MacOS X 10.2 (Jaguar), Classic applications should show up in the suggested applications list, and can be assigned. In MacOS X 10.3 (Panther), Classic applications no longer show up in the suggested lists, but can still be assigned by using the "Other..." option. In MacOS X 10.4 (Tiger), Classic applications no longer appear to work at all. This is most like due to the use of "bundle identifiers" (see question and answer further down), which are a MacOS X concept that no Classic applications will have.

LaunchServices settings (whether set through RCDefaultApp, Finder's Get Info panel, or Safari's default browser setting) are stored in the file ~/Library/Preferences/com.apple.LaunchServices.plist in each user's account. This file can be viewed with Property List Editor, although some of the values may not make much sense. The format of the file is somewhat different depending on MacOS version. Deleting or moving this file will return all settings to the system defaults.

LaunchServices also keeps a database of all applications it knows about (usually automatically added when the user views a folder with applications in Finder). In MacOS X 10.2, this database is kept in the /Library/Caches/com.apple.LaunchServices.LocalCache.csstore and ~/Library/Caches/com.apple.LaunchServices.UserCache.csstore files; in MacOS X 10.3 it is kept at /Library/Caches/com.apple.LaunchServices.6B.csstore; in MacOS X 10.4 there are multiple files in /Library/Caches/ named com.apple.LaunchServices-[digits].csstore.

In the 10.3.9 release, LaunchServices changed so that a user could not "see" applications stored in other users' accounts. Unfortunately, a low-level LaunchServices function will still attempt to obtain information from these apps, and go into an infinite loop trying (resulting in the spinning beach ball).

The only solutions to this problem that I have seen are to either move the applications in to the /Applications folder, or to reset the LaunchServices database. To reset the database, you can use this hint:

http://www.macosxhints.com/article.php?story=20031215144430486

Some versions of TinkerTool may also have a similar function. Following this step, the problem should hopefully not recur. Unfortunately this will also reset the "application-has-been-launched-before" flags, so you will get the alert panels when you open files for an application for the first time.

If an application's creator code is set on a file, that application is still used to open the file, regardless of the LaunchServices settings (which is what RCDefaultApp modifies). More information can be found at Apple's web site, for example Launch Services Concepts. The details of this process can change between operating system versions. RCDefaultApp is not invoked at this stage; it merely changes the LaunchServices settings used by Finder (and other applications).

This means that LaunchServices knows about two copies of OmniWeb 4.5 on your system. It appears that LaunchServices will only allow one of the copies to be used in this situation, but since it is not easy to tell which version is chosen (the rules change between operating system versions), RCDefaultApp displays them both. After setting, RCDefaultApp immediately reverts to the one that LaunchServices will actually use.

Through MacOS X 10.3 (Panther), LaunchServices allowed you to assign different versions of an application (although it would only allow one copy with the same version). In MacOS X 10.4 (Tiger), LaunchServices was changed to be based around "bundle identifiers", which is supposed to be a unique identifier for an application, and is typically the same across multiple versions (it is the same name used for the application's preferences file in ~/Library/Preferences). If there are multiple copies of an application installed which have the same bundle identifier, LaunchServices will choose the "best" version with that identifier to use -- most often, the latest version. There does not seem to be any way around this, so as soon as you install a newer version of an application, that will become the version used by LaunchServices. If you try to assign an earlier version of the application, the setting will "snap back" to the later version.

Following a security update in the MacOS 10.3.9 timeframe, LaunchServices will not allow an application to show as assigned if it has never been launched before. Oddly, the assignment was most likely in fact made successfully, but RCDefaultApp can not confirm that and so will "snap back" to another application. Usually, just running the application is enough to fix this, or possibly double-clicking on a file that will cause that application to open (meaning you will get the warning panel notifying you that this is the first time you have launched that application).

For a ftp:// URL that points to a file, Safari handles it directly and downloads it. The only way to control if it's opened or not is Safari's "Open safe files" preference. For URLs that point to a directory, Safari will hand them to LaunchServices, and the setting as shown in RCDefaultApp will be used.

Unfortunately, this is something that Safari does directly without consulting LaunchServices, so there is nothing that RCDefaultApp can do to affect it. The only option appears to be to right- or control-click on a link and choose the "Download Linked File As..." option, which will let you choose a directory and will not attempt to decompress the file.

Under Panther, for binary executables that have no extension, it turns out that Finder uses the .tool extension setting to determine the application to use (by default, Terminal.app). Changing the application for the "tool" extension in RCDefaultApp will therefore change the the association for most Unix executables. For shell scripts with no extension, it depends on the type of shell script (determined by the first line in the script). For perl scripts (i.e. scripts that have #!/usr/bin/perl on the first line), the application set for the "pl" extension is used; for python scripts, the "py" extension is used; and for Bourne shell (/bin/sh) scripts the "sh" extension is used. Presumably "csh", "bash", etc. are used for other types of shell scripts. It is unknown if Finder or LaunchServices performs these shell script/extension mappings.

Under Jaguar, the "command" extension was registered by Terminal, so naming scripts with that extension is the easy way to get double-clickable scripts to open in Terminal. This still works in Panther.

It appears as though Quicken.app requires that its data files be assigned the appropriate file type, or else it will not open the files. This is contrary to the MacOS X guidelines, which say that applications should support both file types and extensions, as Safari (and other internet applications) do not use InternetConfig to forcibly set the file type on downloaded files. The same problem may exist with Quickbooks.app.

The correct file type for .qfx files is 'WBCN'. If the developer tools are installed, this may be set with the /Developer/Tools/SetFile utility; otherwise third-party software such as Super Get Info or File Buddy are required.

It appears that Timbuktu has a dependency on the "ssh" URL handler being set to Terminal. If this is changed, the Timbuktu menu bar item may stop functioning.