Mi sono imbattuto in questo oggi su un iMac di un mese. L'unica cosa che non è nuova su di esso è il mio account, che è stato replicato su 5 macchine e 12 versioni principali di MacOS usando Migration Assistant quando possibile, lasciandolo con un bel po 'di cruft in ~ / Library / Preferences /. Sfortunatamente, nelle ultime versioni, Apple ha reso più complicata la pulizia di tale directory eliminando i file perché cfprefsd gestisce le informazioni di preferenza real ed è necessario parlare piacevolmente con l'utilità defaults .
Ad ogni modo, mi piace che ogni volta che ho provato a cambiare la preferenza ho ottenuto una sequenza di voci di registro come questa:
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
Inoltre, sia defaults domains che alcune dozzine di file in Preferenze mi hanno detto che la maggior parte delle applicazioni con un dominio di default appropriato come com.example.appname anche aveva un valore predefinito dominio come com.example.appname.LSSharedFileList che conteneva elenchi di file utilizzati di recente. Tranne non sono stati utilizzati file di recente. Nessuno dei file * .LSSharedFileList.plist è stato modificato dalla mia migrazione dalla mia vecchia macchina Yosemite e nessuno dei due aveva com.apple.recentitems.plist. Così ho pulito casa eseguendo questi comandi all'interno di ~ / Library / Preferences /:
defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*
Il comando defaults indica cfprefsd per rimuovere tutte le impostazioni in quel dominio, che lascia un file .plist logicamente vuoto a 42 byte e un file .plist.lockfile a 0 byte che il comando rm rimuove .
defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm *LSSharedFileList.plist*
Meno ovvio, ma essenzialmente la stessa cosa per tutti i domini defaults con LSSharedFileList nei loro nomi
find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm
Ancora meno ovvio, ma apparentemente cruciale. Questa pipeline trova tutti i file * .plist nella directory corrente (che era ~ / Library / Preferences /,) controlla ognuno per validità con plutil -lint , analizza i nomi file di quelli che non sono "OK", li enquota per proteggere da spazi incorporati e simili e rimuoverli tutti. Nel mio caso i file * .plist non validi erano tutti file antichi a 0 byte per roba che non può essere eseguita su El Cap comunque, quindi ero sicuro che non stavo cancellando alcuna informazione effettiva. YMMV !!
find . -size 42c -name "*plist" -delete
Questo ha cancellato tutti i file * .plist lunghi 42 byte, le dimensioni di un plist logicamente vuoto in formato binario. Ne ho visti alcuni in giro e loro potrebbero aver causato il reclamo da sharedfilelistd .
killall sharedfilelistd
Che ha interrotto l'istanza di sharedfilelistd in esecuzione sotto il mio account. Il sistema ha riavviato automaticamente una nuova istanza. Non sono sicuro che fosse necessario, ma mi è sembrato prudente da quando avevo cancellato un gruppo di informazioni dal sottosistema delle preferenze che era collegato al vecchio modo di fare ciò che sharedfilelistd sembra fare in El Cap.
NOTA: Quei 7 comandi sono la versione ridotta di ciò che ho fatto che aveva senso e aveva effetti, sparsi in 3 ore di frugare e testare e cercare di trovare informazioni su sharedfilelistd senza successo .
Vale anche la pena notare che non vi è alcun sudo coinvolto qui, perché ero nella mia ~ / Library / Preferences /, manipolando il mio regno delle preferenze. Il menu Elementi recenti e quindi le sue impostazioni sono specifiche dell'utente, quindi ovunque l'impostazione sia memorizzata (non l'ha mai elaborata ...) deve essere specifica dell'utente, non qualcosa che richiede la correzione da parte di root. C'è una risposta preventiva che include un enorme permesso / ACL / flag wipe inspiegabile, eseguito con sudo, che non ha nemmeno funzionato per l'autore, e può causare seri danni sistemici. Questo non è niente del genere. Si noti inoltre che non richiede la disconnessione, il riavvio, l'avvio in modalità di ripristino o qualsiasi altra operazione che potrebbe essere di disturbo.
