Je suis tombé là-dessus aujourd'hui sur un iMac de moins d'un mois. Le seul élément qui n'est pas récent est mon compte, qui a été reproduit sur 5 machines et 12 versions majeures de macOS en utilisant l'assistant de migration lorsque possible, laissant ainsi un peu de cruft dans ~/Library/Preferences/. Malheureusement, dans les versions récentes, Apple a rendu compliqué de nettoyer ce répertoire de manière efficace en supprimant des fichiers car cfprefsd gère les informations de préférence réelles et vous devez lui parler gentiment avec l'utilitaire defaults.
Quoi qu'il en soit, j'ai remarqué qu'à chaque fois que j'essayais de changer la préférence, j'obtenais une séquence d'entrées de journal comme celle-ci :
Jul 14 18:14:03 extravagant sharedfilelistd[411] : [default] [{contents = "com.apple.LSSharedFileList.RecentApplications"}] List write failed invalid info items: (null) properties: (null)
Jul 14 18:14:03 extravagant sharedfilelistd[411] : -[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] : Error getting number of recent items of type 2, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] : New number of recents: 30
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] : Error getting number of recent items of type 1, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] : Error getting number of recent items of type 2, LSSharedFileListCopyProperty returned NULL
Jul 14 18:14:11 extravagant com.apple.preference.general.remoteservice[85562] : 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]) : Service exited due to signal: Killed: 9
Aussi, à la fois default domains et quelques douzaines de fichiers dans les Préférences m'ont indiqué que la plupart des applications avec un domaine de défaut approprié comme com.example.appname aussi avaient un domaine de défaut comme com.example.appname.LSSharedFileList qui contenait des listes de fichiers récemment utilisés. Sauf qu'il ne s'agissait pas du tout de fichiers récemment utilisés. Aucun des fichiers *.LSSharedFileList.plist n'avait changé depuis ma migration depuis mon ancienne machine Yosemite, et ni com.apple.recentitems.plist. Donc j'ai fait le ménage en exécutant ces commandes à l'intérieur de ~/Library/Preferences/ :
defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*
La commande defaults dit à cfprefsd de supprimer tous les paramètres de ce domaine, ce qui laisse un fichier .plist logiquement vide de 42 octets et un fichier .plist.lockfile de 0 octet que la commande rm supprime.
defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm *LSSharedFileList.plist*
Moins évident, mais essentiellement la même chose pour tous les domaines defaults avec LSSharedFileList dans leur nom
find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm
Même moins évident, mais apparemment crucial. Ce pipeline trouve tous les fichiers *.plist dans le répertoire actuel (qui était ~/Library/Preferences/), vérifie chacun d'entre eux pour leur validité avec plutil -lint, analyse les noms de fichiers de ceux qui ne sont pas "OK", les encadre entre guillemets pour les protéger des espaces incorporés et supprime tous. Dans mon cas, les fichiers *.plist invalides étaient tous des fichiers antiques de 0 octet pour des choses qui ne peuvent de toute façon pas s'exécuter sur El Cap, donc j'étais sûr de ne pas supprimer d'informations réelles. YMMV!!
find . -size 42c -name "*plist" -delete
Cela a balayé tous les fichiers *.plist qui faisaient 42 octets, la taille d'un plist logiquement vide en format binaire. J'en avais quelques-uns qui traînaient et ils pourraient avoir été la cause de la plainte de sharedfilelistd.
killall sharedfilelistd
Cela a terminé l'instance de sharedfilelistd qui fonctionnait sous mon compte. Le système a redémarré automatiquement une nouvelle instance. Je ne suis pas sûr que cela était nécessaire, mais cela semblait prudent puisque je venais d'effacer un tas d'informations du sous-système de préférences qui était lié à l'ancienne méthode de ce que sharedfilelistd fait apparemment dans El Cap.
NOTE : Ces 7 commandes sont la version abrégée de ce que j'ai fait qui avait du sens et des effets, parsemées sur 3 heures d'exploration et de test et d'essais pour trouver des informations sur sharedfilelistd en vain.
Il convient également de noter qu'aucun sudo n'est impliqué ici, car j'étais dans mes propres ~/Library/Preferences/, manipulant mon propre royaume de préférences. Le menu Éléments récents et donc ses réglages sont spécifiques à l'utilisateur donc où que ce réglage soit stocké (je n'ai jamais trouvé ça...), doit être propre à l'utilisateur également, et non quelque chose nécessitant des droits d'administrateur pour être réparé. Il y a une réponse précédente qui inclut une suppression massive inexpliquée de permissions/ACL/flags, exécutée avec sudo, qui n'a même pas fonctionné pour l'auteur, et qui pourrait entraîner des dommages systémiques graves. Ce n'est rien de tel. À noter également qu'il ne nécessite pas de déconnexion, de redémarrage, de démarrage en mode de récupération, ou de faire quoi que ce soit d'autre susceptible d'être perturbateur.
