Ich bin heute auf einem einmonatigen iMac darauf gestoßen. Das einzige, was nicht ganz aktuell ist, ist mein Konto, das mit dem Migrationsassistenten auf 5 Maschinen und 12 Hauptversionen von MacOS repliziert wurde, und das mit ein wenig Cruft in ~ / Library / Preferences / belassen wurde. Unglücklicherweise hat es Apple in den letzten Versionen kompliziert gemacht, dieses Verzeichnis effektiv zu bereinigen, indem Dateien in den Papierkorb verschoben wurden, da cfprefsddie eigentlichen Einstellungsinformationen verwaltet werden und Sie mit dem defaultsDienstprogramm gut darüber sprechen müssen .
Wie auch immer, ich finde es toll, dass ich jedes Mal, wenn ich versuchte, die Einstellung zu ändern, eine Folge von Protokolleinträgen wie die folgende erhalten habe:
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
Außerdem haben defaults domainsmir beide und ein paar Dutzend Dateien in den Voreinstellungen mitgeteilt, dass die meisten Anwendungen mit einer geeigneten Standarddomäne wie com.example.appname auch eine Standarddomäne wie com.example.appname.LSSharedFileList hatten, die Listen kürzlich verwendeter Dateien enthielt. Außer, dass es sich überhaupt nicht um kürzlich verwendete Dateien handelt. Keine der * .LSSharedFileList.plist-Dateien hatte sich seit meiner Migration von meinem alten Yosemite-Computer geändert, und com.apple.recentitems.plist hatte sich auch nicht geändert. Also habe ich das Haus gesäubert, indem ich diese Befehle in ~ / Library / Preferences / ausgeführt habe:
defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*
Der defaultsBefehl fordert Sie cfprefsdauf, alle Einstellungen in dieser Domäne zu entfernen. Dadurch verbleiben eine logisch leere .plist-Datei mit 42 Byte und eine .plist.lock-Datei mit 0 Byte, die vom rmBefehl entfernt werden.
defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm *LSSharedFileList.plist*
Weniger offensichtlich, aber im Wesentlichen dasselbe für alle defaultsDomänen mit LSSharedFileList im Namen
find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm
Noch weniger offensichtlich, aber anscheinend entscheidend. Diese Pipeline findet alle * .plist-Dateien im aktuellen Verzeichnis (das war ~ / Library / Preferences /,) prüft jede auf Gültigkeit mit plutil -lint, analysiert die Dateinamen derjenigen, die nicht "OK" sind, und fragt sie zum Schutz ab eingebettete Räume und dergleichen und entfernt sie alle. In meinem Fall waren die ungültigen * .plist-Dateien alle 0-Byte-Antikdateien für Dinge, die auf El Cap sowieso nicht ausgeführt werden können. Ich war mir also sicher, dass ich keine tatsächlichen Informationen löschte. YMMV !!
find . -size 42c -name "*plist" -delete
Dies löschte alle * .plist-Dateien, die 42 Byte lang waren, die Größe einer logisch leeren plist im Binärformat. Ich hatte ein paar von denen herumhängen und sie könnten die Beschwerde von verursacht haben sharedfilelistd.
killall sharedfilelistd
Dadurch wurde die sharedfilelistdAusführung unter meinem Konto beendet. Das System hat eine neue Instanz automatisch neu gestartet. Ich bin mir nicht sicher, ob dies erforderlich war, aber es erschien mir vernünftig, da ich gerade eine Reihe von Informationen aus dem Subsystem "Einstellungen" gelöscht hatte, die mit der alten Vorgehensweise sharedfilelistdin El Cap in Verbindung standen.
ANMERKUNG: Diese 7 Befehle sind die gekürzte Version von dem, was ich getan habe, was Sinn machte und Auswirkungen hatte. Sie verteilten sich auf 3 Stunden Stöbern und Testen und Versuchen, Informationen zu finden sharedfilelistd, ohne Erfolg.
Es ist auch erwähnenswert, dass es sudohier keine Beteiligung gibt, da ich mich in meiner eigenen ~ / Library / Preferences / befand und meinen eigenen Einstellungsbereich manipulierte. Das Menü "Zuletzt verwendete Elemente" und damit seine Einstellungen sind benutzerspezifisch. Daher muss diese Einstellung, wo immer sie gespeichert ist (nie geklärt ...), auch benutzerspezifisch sein, und es muss kein Root-Benutzer angemeldet sein, um sie zu reparieren. Es gibt eine frühere Antwort, die eine unerklärliche massive Erlaubnis / ACL / Flag-Löschung enthält, mit sudo ausgeführt wird, die nicht einmal für den Autor funktioniert hat und schwerwiegenden Systemschaden verursachen kann. Das ist nichts dergleichen. Beachten Sie auch, dass Sie sich nicht abmelden, neu starten, im Wiederherstellungsmodus booten oder andere Maßnahmen ergreifen müssen, die möglicherweise stören.
