gistfile1.txt

I've been fighting the same problem and have to say the hint provided here about resetting the launch services, and letting `launchd` do this at login (via Lingon) is invaluable. Thanks a lot for that, it makes FileVault far more usable!

After using this for a while, I have however discovered a side effect of resetting the launch services that is rather annoying--but I have also found a solution for it.

The _problem_ is that after resetting the launch services, calling a protocol handler registered by a user installed application is considered a **first time call** again, meaning it needs to be confirmed by the user (unless the app has been started directly before the call). Examples I stumbled upon are:

* bookmarking through the Pukka bookmarklet
* opening an Evernote note from a Spotlight search
* calling a `man` page in Safari through Bwana.

Others abound, as most apps seem to install some kind of protocol handler nowadays.

The _solution_ to this is to change the file ownership of the app bundles in question to **`root`**--which is the default for Apple's own apps anyway (including those not part of the OS, like iLife, iWorks)--as app bundles owned by `root` seem not to be subject to first launch protocol handler confirmation.

	sudo find /Applications -iname "*.app" \! -user root -prune -exec chown -R root \{} \;

will do the trick. I'd also recommend setting group ownership to **`admin`** instead of `staff`, and setting permissions for the group to **`rwx`**, to facilitate app management after the ownership change (again, these are the Apple defaults, as `ls -le` will tell you).

	sudo find /Applications -iname "*.app" -group staff -prune -exec chown -R :admin \{} \;
	sudo find /Applications -iname "*.app" \! -perm g=rwx -prune -exec chmod -R g=rwx \{} \;

will do that for you (don't use `find \! -group admin` as some apps, notably System Preferences, are set to the `wheel` group). Reset launch services after that and you are good to go. You will need to provide an administrator password to manipulate all app bundles in the /Applications directory henceforth, but I find it a matter of discussion if this can be qualified as an annoyance, or rather as a security improvement :).

This being said, two other very minor remarks are:

1. the syntax for `lsregister` has changed along with its location under Leopard (though the syntax given above seems to be only deprecated, not unsupported). A full reset is now executed with the command **`lsregister -kill -r -all system,local,user`** it seems.

2. redirecting the output of a command to `/dev/null` in a `launchd` agent is listed as a thing not to do by the `launchd.plist` man page, unless I'm mistaken.

These minor quibbles do not detract in any way from the merit of having figured out the reset would do the trick. Again, kudos for that!