Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

FileVault and Launch Services

I seem to have a conflict between FileVault and Launch Services. Whenever I assign a custom URL handler or file extension, the settings are forgotten on a reboot.

Can someone please verify if this happens with their set up too? It's exceptionally annoying for me, even though I don't reboot that often.

To duplicate:
1) Create a new account
2) Log in to the new account.
3) Enable FileVault
4) Modify Launch Services settings. I usually start Firefox and set it as the default browser when prompted. Changing assignments for file extensions (using Finder or RCDefaultApp) will also exhibit the same issue.
5) Reboot (don't just log out) and, if necessary, log into the new account.
6) Check Launch Services settings again. In my case, I start Firefox again. It will prompt to be set as the default browser again, indicating that the previous settings were not retained.

Some cases, it seems the settings seem to be retained over one reboot, but will be lost the next. Settings will be preserved when only logging in and out without a reboot.

The problems go away when I disable FileVault. I've checked ~/Library/Preferences/com.apple.LaunchServices.plist and it's fine across reboots. It seems that LaunchServices itself isn't reading the file when its in FileVault.

This a a clean installation of Leopard, not an upgrade of any sort.

Thanks in advance.

MacBook, Mac OS X (10.5)

Posted on Nov 12, 2007 8:39 PM

Reply
Question marked as Best reply

Posted on Nov 19, 2007 6:35 AM

Yes I see it too. In my case it seems com.apple.LaunchServices.plist is resetting with every boot. I typically change various video types from quicktime to vlc among other things. I'm plaaning on seeing if I can work around this with a login script.
In addition to this behavior I cannot get launch services to truly respect file extensions. My primary example: I have digital comics. These are typically zipped or rared sets of jpegs, using zip/rar purely for packaging purposes not compression. The extensions are then standardly set to cbz or cbr (comic book zip/rar). If I assign these to the comic reader, it works until reboot, but .zip and. rar extensions are also mapped to the reader. The opposite problem occurs if I set the zip/rar to something , The plist file does not record the extensions at all in in some cases, going strictly by the type of file, which actually are not different. This was no problem in 10.4.
77 replies
Question marked as Best reply

Nov 19, 2007 6:35 AM in response to thirteen37

Yes I see it too. In my case it seems com.apple.LaunchServices.plist is resetting with every boot. I typically change various video types from quicktime to vlc among other things. I'm plaaning on seeing if I can work around this with a login script.
In addition to this behavior I cannot get launch services to truly respect file extensions. My primary example: I have digital comics. These are typically zipped or rared sets of jpegs, using zip/rar purely for packaging purposes not compression. The extensions are then standardly set to cbz or cbr (comic book zip/rar). If I assign these to the comic reader, it works until reboot, but .zip and. rar extensions are also mapped to the reader. The opposite problem occurs if I set the zip/rar to something , The plist file does not record the extensions at all in in some cases, going strictly by the type of file, which actually are not different. This was no problem in 10.4.

Nov 19, 2007 11:24 AM in response to Terry Reeves

In my case, after a reboot, com.apple.LaunchServices.plist is always preserved, but not read. If I try to make any changes to Launch Services's settings, the .plist will be overwritten with just the new changes. Upon reboot, even these new changes will be forgotten. In your case, something may be making changes at each reboot (maybe a program started at login), making it appear that the .plist file is not retained.

A temporary workaround for me is to delete the Launch Services caches at <pre>/Library/Caches/com.apple.LaunchServices-023{0,${UID}}.csstore</pre> and reboot. LaunchServices will then read the correct settings from the .plist on the next reboot.

Another workaround is to run:
<pre>/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Lau nchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user</pre> which should take effect immediately.

I must stress that both of these are workarounds, not solutions. I think the bug is probably that Leopard tries to initialize Launch Services before the user's FileVault volume is mounted. This might be necessary because of the new quarantine functionality that Launch Services handles.

Nov 25, 2007 5:07 PM in response to thirteen37

Just to extend thirteen37's suggestions,

I created an Automator workflow that runs the shell command

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchSe rvices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user

I saved it as an application in my home directory and set that application to run at login through System Preferences. It is still not a fix, but it at least automates the work around.

Dec 13, 2007 1:19 PM in response to thirteen37

- Sometimes, menuitems do not start with session login. Have to restore all manually.
- World of Warcraft expansion and big patches not installable (identifies a file part of the install as corrupt)
- Launch services forget selected applications and fall back to default (will open safari instead of firefox, preview instead of adobe reader, etc.)

Apart from the launchservices configuration loss, I have also lost twice the mouse buttons configuration for expose and dashboard.

repeated:
- the Wow game itself wo'n install
- the expose mouse button configuration is sometimes lost, and must be re-assigned


The bug is: Problem ID: 5575270
The bug was:
01-Nov-2007 04:34 PM Cloned from problemID rdar://problem/5165891 by: SABRINA FULLHART.



The first answer from apple to the bug was:

Engineering has requested the following information in order to further investigate this issue:

Please know that we have been able to get the same behavior in our everyday usage of the system. If possible, could you supply detailed steps that cause these problems to happen consistently and repeatedly?


<http://bugreport.apple.com>

Dec 13, 2007 2:37 PM in response to Austin Jackson

There is really no need to do that. "lsregister" is automatically run when you startup anyway, and running a secondary instance is only likely to cause problems. See Launch Services Programming Guide: Application Registration:

All applications available on the user’s system must be registered to make them known to Launch Services and copy their document binding and other information into its database. It isn’t ordinarily necessary to perform this task explicitly, since a variety of utilities and services built into the Mac OS X system software take care of it automatically:


•A built-in background tool (lsregister), 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.)


Hope this helps....

Message was edited by: MarkDouma®

Dec 18, 2007 3:23 AM in response to MarkDouma®

Yeah, that's what the docs say. What actually happens (my guess, based on the behavior of the system) is that lsregister scans the domains before the FileVault volume is mounted. Which then causes it to omit everything in the user's domain. It is definitely necessary to run it after the volume is mounted. The question is when after?

I don't know how long lsregister runs for in the background, but I suspect it's done before anything in the Login pane starts running. If you run it too late, some apps at startup won't benefit from the updated information. If you run it too soon, you risk messing with the instance that's run automatically, or even with FileVault.

Dec 18, 2007 5:53 PM in response to thirteen37

Add one victim to the list.

Another observation: there seems to be something fundamentally flawed with Filevault plus Launch Services. Every now and then, Leopard fails to mount my FV sparsebundle correctly. I end up with mangled paths: ~ points to the fake user directory containing the FV image. So I get no lock item for my home directory, the desktop stays empty, and the system fails to load some preferences.

In sum, FileVault appears to be the opposite of it's function: unreliable, insecure, and a big risk altogehter. And because we're on a half-proprietary OS, we can't even turn on filesystem encryption on the filesystem level.

Now I only wish the ZFS encryption project were finished and OS X would integrate it fully.

FileVault and Launch Services

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.