Wpadłem na to dzisiaj na miesięcznym komputerze iMac. Jedyne, co nie jest świeże na tym koncie, to moje konto, które zostało zreplikowane na 5 komputerach i 12 głównych wersjach MacOS przy użyciu Migration Assistant, gdy jest to możliwe, pozostawiając dość sporą cruft w ~ / Library / Preferences /. Niestety, w ostatnich wersjach Apple skomplikowało skuteczne czyszczenie tego katalogu poprzez usuwanie plików, ponieważ cfprefsdzarządza prawdziwymi informacjami o preferencjach i musisz ładnie z nim porozmawiać za pomocą tego defaultsnarzędzia.
W każdym razie uwielbiam to, że za każdym razem, gdy próbowałem zmienić preferencje, otrzymywałem sekwencję wpisów dziennika:
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
Ponadto, zarówno defaults domainsi kilkadziesiąt plików w Preferencjach powiedziało mi, że większość aplikacji z prawidłową domeną domyślną, taką jak com.example.appname, również miała domenę domyślną, taką jak com.example.appname.LSSharedFileList, która zawierała listy ostatnio używanych plików. Tyle że ostatnio nie były wcale używane. Żaden z plików * .LSSharedFileList.plist nie zmienił się od czasu mojej migracji z mojej starej maszyny Yosemite i żaden z nich nie miał com.apple.recentitems.plist. Więc wyczyściłem dom, uruchamiając te polecenia w ~ / Library / Preferences /:
defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*
defaultsKomenda mówi cfprefsdaby usunąć wszystkie ustawienia w tej domenie, która opuszcza 42-bajtowy logicznie pusty .plist plik i 0-bajt .plist.lockfile plik, który rmusuwa polecenie.
defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm *LSSharedFileList.plist*
Mniej oczywiste, ale zasadniczo to samo dla wszystkich defaultsdomen z LSSharedFileList w ich nazwach
find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm
Jeszcze mniej oczywiste, ale pozornie kluczowe. Ten potok znajduje wszystkie pliki * .plist w bieżącym katalogu (którym był ~ / Library / Preferences /,) sprawdza poprawność każdego z nich plutil -lint, analizuje nazwy plików, które nie są „OK”, przywołuje je do ochrony osadzone spacje itp. i usuwa je wszystkie. W moim przypadku wszystkie niepoprawne pliki * .plist były 0-bajtowymi antykami dla rzeczy, które i tak nie mogą działać na El Cap, więc byłem pewien, że nie usuwam żadnych rzeczywistych informacji. YMMV !!
find . -size 42c -name "*plist" -delete
Spowodowało to usunięcie wszystkich plików * .plist o długości 42 bajtów, wielkości logicznie pustej listy w formacie binarnym. Kilka osób kręciło się wokół i mogły być przyczyną skargi sharedfilelistd.
killall sharedfilelistd
To zakończyło sharedfilelistddziałanie na moim koncie. System automatycznie zrestartował nową instancję. Nie jestem pewien, czy było to potrzebne, ale wydawało się rozsądne, ponieważ właśnie usunąłem garść informacji z podsystemu preferencji, które były związane ze starym sposobem robienia tego, co sharedfilelistdnajwyraźniej robi się w El Cap.
UWAGA: Te 7 poleceń jest skróconą wersją tego, co zrobiłem, co miało sens i miało efekty, rozrzucone w ciągu 3 godzin grzebania i testowania oraz próby znalezienia informacji sharedfilelistdbezskutecznie.
Warto również zauważyć, że nie ma sudotu żadnego związku , ponieważ byłem w swoim własnym ~ / Library / Preferences /, manipulując swoim własnym obszarem preferencji. Menu Ostatnie elementy, a tym samym jego ustawienia są specyficzne dla użytkownika, więc gdziekolwiek to ustawienie jest przechowywane (nigdy tego nie wymyślono ...) musi być również specyficzne dla użytkownika, a nie coś, co wymaga rootowania do naprawienia. Istnieje wcześniejsza odpowiedź, która obejmuje niewyjaśnione masowe pozwolenie / ACL / czyszczenie flag, uruchamiane z sudo, które nawet nie działało dla autora i może spowodować poważną szkodę systemową. To nic takiego. Należy również pamiętać, że nie wymaga wylogowywania, ponownego uruchamiania, uruchamiania w trybie odzyskiwania lub robienia czegokolwiek, co może być szkodliwe.