Report-an-Apple-Bug Friday! 75: NSUserDefaults and /Library/Preferences

2008-11-14 23:16:28 -08:00

This bug is NSUserDefaults does not look in /Library/Preferences. It was filed on 2008-11-14 at 23:09 PST.


Summary:

NSUserDefaults ignores plist files in /Library/Preferences when collecting the application’s preferences.

Steps to Reproduce:

  1. Ask [NSUserDefaults standardUserDefaults] for the value of a preference that is only defined in a plist in /Library/Preferences.

Expected Results:

NSUserDefaults, having included that plist when collecting the user’s preferences for the current application, returns the value for the preference.

Actual Results:

NSUserDefaults returns nil, 0, or NO.

Regression:

This first broke in Mac OS X 10.5.3. Prior to that version, it worked.

Workaround:

Use CFPreferences.

Notes:

File: PreferencesChecker-r6.tbz

A test app is included. In with the Xcode project is a plist file, which you should copy to /Library/Preferences (NOT ~/Library/Preferences) for testing.

When you run the application, it presents two editable fields for you to set the bundle identifier and preference key to look up. Their values default to look up one of the keys from the provided plist file; thus, if you have installed that file in the correct location, you should see the value “Foo” show up in the “Local” output field.

The test app uses NSUserDefaultspersistentDomainForName: to retrieve the whole preferences dictionary, and then uses dictionary access to retrieve the preference. This is not the only way to reproduce the problem; two others, including the one I wrote in the Steps to Reproduce, are included in the source code, commented out.

2 Responses to “Report-an-Apple-Bug Friday! 75: NSUserDefaults and /Library/Preferences”

  1. Ken Says:

    Any progress on this?

    Personally, I think the current behavior is more consistent with the name since it is the “user’s preferences”. (Don’t know how it was documented prior to 10.5.3, so can’t comment on that.)

    But then it is strange that you need to use a Core Foundation API to access the global preferences when everything else is Cocoa. And writing to /Library/Preferences is even more awkward since you need a helper code that runs as root. Shouldn’t there be some kind of service that manage this?

    Just wondering…

  2. Peter Hosey Says:

    Yup. It’s fixed as of 10.6.1.

Leave a Reply

Do not delete the second sentence.