Previous 1 2 3 Next 77 Replies Latest reply: Sep 8, 2009 3:26 AM by Michael Kuck
thirteen37 Level 1 (0 points)
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/ 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)
  • Terry Reeves Level 1 (5 points)
    Yes I see it too. In my case it seems 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.
  • thirteen37 Level 1 (0 points)
    In my case, after a reboot, 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/{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.
  • Austin Jackson Level 1 (5 points)
    I can confirm this. Same exact problem.
  • Austin Jackson Level 1 (5 points)
    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.
  • GunnarSchroeder Level 4 (1,140 points)
    Hits me, too. I use my profile from 10.4.x from an upgrade install.

    Message was edited by: GunnarSchroeder
  • Pascal Pfiffner Level 1 (25 points)
    Same problem here. Thanks for the hints, I hope this helps.
  • thirteen37 Level 1 (0 points)
    Does anybody know the best way to bring this to Apple's attention? 10.5.1 still has the issue, but I sure hope it can be fixed before 10.5.2.
  • GunnarSchroeder Level 4 (1,140 points)
    I count us lucky if it gets fixed with 10.5.2.
  • jakaj Level 1 (0 points)
    I have this problem too. In addition to that, firewall rules are also lost on every reboot (I use "Set access for specific services and applications").
  • loniux Level 1 (0 points)

    I opened the bug 5575270 almost one year ago with Tiger. They Ignore it and think Leopard solved it. No way!
    It also causes not only the LaunchServices Alzheimer, but also you cannot install WOW or update Adobe Reader.

    Bye all.
  • thirteen37 Level 1 (0 points)
    I'm not sure if your problem is the same. As noted above, this bug has only been observed in Leopard. Most, if not all, of us have used a similar set up under Tiger with no issues.

    Please describe your problem. Does it involve FileVault?
  • loniux Level 1 (0 points)
    - 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.

    - 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?

  • MarkDouma® Level 6 (9,850 points)
    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®
  • thirteen37 Level 1 (0 points)
    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.
Previous 1 2 3 Next