It’s not a dictionary?  Well, that’s right!  My preferences aren’t a dictionary….

Updated 10/27/2009, with a potential solution…
Updated 02/13/2010, with a solution…

Seriously though, if you see the following in your console log:

9/18/09 12:36:49 PM PreferenceSyncClient[60967] Preference plist was NOT a dictionary.
9/18/09 12:36:49 PM PreferenceSyncClient[60967] Preference plist was NOT a dictionary.
9/18/09 12:36:49 PM PreferenceSyncClient[60967] Preference plist was NOT a dictionary.
9/18/09 12:36:49 PM PreferenceSyncClient[60967] Preference plist was NOT a dictionary.

You might have an small issue to resolve…

In my case, that message has been occurring every hour… From some research it appears to be MobileMe related… But when I checked the MobileMe status on Nerv, I found a funny thing…

MobileMe was turned off… But I know I see the MobileMe Widget activated, and that message was occurring… I re-activated MobileMe, and forced a sync…

Now, I am waiting to see if that resolved the error in the log…… And it hasn’t…

So, if anyone has any suggestions on resolving this issue, please feel free to let me know…

Here’s another case of a similar issue…Except that he’s had high CPU use, and a stuck MobileMe sync...

Update — 9/24/2009

There has been some speculation that this maybe related to MobileMe Syncing (as discussed above), Google Syncing, and at least one set of fingers have been pointed towards Growl.  I have submitted this case to Apple under Radar # 7249814.

Update — 9/25/2009

As far as I can tell, all of my preferences (~/library/Preferences & /Library/Preferences) are intact, and not corrupted…

If you would like to test this, use this small bit of python code:


import sys
import os
directory_to_scan = sys.argv[1].strip()
print directory_to_scan
files_in_directory = os.listdir ( directory_to_scan )
for x in files_in_directory:
if x.upper().find (".PLIST") <> -1:
os.system ('sudo plutil -s "%s/%s"; # Use Plutil in "lint" mode to check the plist' % (directory_to_scan,x) )


Update — 10/27/2009

A posting on the Apple discussions thread mentioned:

I found the problem. It was Google trying to connect to an unknown server. I had downloaded Chrome but didn’t like it. Anyway, I used HoudahSpot to find everything Google after LittleSnitch reported Google trying to “phone home”. I trashed everything GOOGLE and restarted last night. The console message is now gone.

That got me thinking….  I did at one time have Address Book configured to sync with Google…  I checked and that is still turned on.  I have turned it off, and I am currently waiting to see if that message disappears….

The files that were created when I configured it, are:

• com.google.GoogleContactSyncAgent.plist @ ~/Library/LaunchAgents
• com.google.ContactSync (folder) @ ~/Library/Application Support
• com.google.GoogleContactSync.plist @ ~/Library/Preferences

So, if we take the error message at face value, either the LaunchAgent or preference file maybe damaged…

But of course, the root cause of this issue is that the error message is uninformative, and does not indicate which plist “is not a dictionary”. If Apple had indicated which plist was the cause, we would not be investigating this issue.

Update #2 — 10/27/2009

Well, that did not seemingly solve the problem for me….  I still have the preferences message appearing in the console log on a regular basis…

Update #3 – 2/13/2010

I believe that a solution has been found in the Apple Customer forums…  The following command, will reproduce the plist was not a dictionary error message…

/System/Library/CoreServices/PreferenceSyncClient.app/Contents/MacOS/PreferenceSyncClient –sync –periodic

and the next command will display all the files that have any array in it…

egrep ‘^<array>’ ~/Library/Preferences/*

I do not suggest deleting these files, instead move them to a different directory.  For example, my iTunes preferences was detected as a file in question…  As well as the iCal alarmscache file….  And neither application was indicating or showing any issues…  So move the file to a different location, and test to ensure that you are not receiving a false positive….

egrep just does a pattern match, so it just scanning the files for “<array>” being found at the beginning of a line.  I hope to have this confirmed as a solution in a few hours, when I don’t see this error message in the log file any longer…