I ran into this today on a month-old iMac. The only thing that isn't fresh about it is my account, which has been replicated across 5 machines and 12 major MacOS versions using Migration Assistant when possible, leaving it with a fair bit of cruft in ~/Library/Preferences/. Unfortunately, in recent versions Apple has made it complicated to clean up that directory effectively by trashing files because cfprefsd
manages the real preference info and you need to talk nicely to it with the defaults
utility.
Anyway, I fond that every time I tried to change the preference I got a sequence of log entries like this:
Jul 14 18:14:03 extravagant sharedfilelistd[411] <Critical>: [default] [<CFString 0x7fff77ea0e00 [0x7fff77f58440]>{contents = "com.apple.LSSharedFileList.RecentApplications"}] List write failed invalid info items: (null) properties: (null)
Jul 14 18:14:03 extravagant sharedfilelistd[411] <Error>: -[ListStore writeListItems:properties:withListIdentifier:notificationHander:] [com.apple.LSSharedFileList.RecentApplications] List write failed invalid info items: (null) properties: (null)
Jul 14 18:14:05 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 2, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: New number of recents: 30
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 1, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 2, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] <Warning>: Error getting number of recent items of type 3, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:13 extravagant com.apple.xpc.launchd[1] (com.apple.preference.general.remoteservice[85562]) <Notice>: Service exited due to signal: Killed: 9
Also, both defaults domains
and a few dozen files in Preferences told me that most applications with a proper defaults domain like com.example.appname also had a defaults domain like com.example.appname.LSSharedFileList which contained lists of recently used files. Except they weren't recently used files at all. None of the *.LSSharedFileList.plist files had changed since my migration from my old Yosemite machine, and neither had com.apple.recentitems.plist. So I cleaned house by running these commands inside ~/Library/Preferences/:
defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*
The defaults
command tells cfprefsd
to remove all of the settings in that domain, which leaves a 42-byte logically empty .plist file and a 0-byte .plist.lockfile file which the rm
command removes.
defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm *LSSharedFileList.plist*
Less obvious, but essentially the same thing for all defaults
domains with LSSharedFileList in their names
find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm
Even less obvious, but apparently crucial. This pipeline finds all of the *.plist files in the current directory (which was ~/Library/Preferences/,) checks each one for validity with plutil -lint
, parses out the filenames of those that are not "OK", enquotes them to protect from embedded spaces and the like, and removes them all. In my case the invalid *.plist files were all 0-byte antique files for stuff that can't run on El Cap anyway, so I was sure I was not deleting any actual information. YMMV!!
find . -size 42c -name "*plist" -delete
This swept out any *.plist files that were 42-bytes long, the size of a logically empty plist in binary format. I had a few of those hanging around and they might have been causing the complaint from sharedfilelistd
.
killall sharedfilelistd
That terminated the instance of sharedfilelistd
running under my account. The system restarted a fresh instance automatically. I'm not sure this was needed, but it seemed prudent since I had just wiped out a bunch of information from the preferences subsystem that was related to the old way of doing what sharedfilelistd
apparently does in El Cap.
NOTE: Those 7 commands are the abridged version of what I did that made sense and had effects, scattered across 3 hours of poking around and testing and trying to find info on sharedfilelistd
to no avail.
It is also worth noting that there's no sudo
involved here, because I was in my own ~/Library/Preferences/, manipulating my own preferences realm. The Recent Items menu and hence its settings are user-specific so wherever that setting is stored (never worked that out...) has to be user-specific as well, not something requiring root to fix. There's a prior response that includes an unexplained massive permission/ACL/flag wipe, run with sudo, that didn't even work for the author, and may cause serious systemic harm. This is nothing like that. Also note that it does not require logging out, rebooting, booting in Recovery Mode, or doing anything else likely to be disruptive.