Encontrei isso hoje em um iMac de um mês. A única coisa que não é novidade é a minha conta, que foi replicada em 5 máquinas e 12 versões principais do MacOS usando o Migration Assistant, quando possível, deixando-o com um pouco de fragilidade em ~ / Library / Preferences /. Infelizmente, nas versões recentes, a Apple dificultou a limpeza eficaz desse diretório, lixeira de arquivos porque cfprefsd
gerencia as informações reais de preferência e você precisa conversar com ele com o defaults
utilitário.
Enfim, gosto de que toda vez que tentei alterar a preferência, recebi uma sequência de entradas de log como esta:
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
Além disso, defaults domains
uma dúzia de arquivos nas Preferências me disseram que a maioria dos aplicativos com um domínio padrão adequado como com.example.appname também tinha um domínio padrão como com.example.appname.LSSharedFileList que continha listas de arquivos usados recentemente. Exceto que eles não foram arquivos usados recentemente. Nenhum dos arquivos * .LSSharedFileList.plist foi alterado desde a minha migração da minha máquina Yosemite antiga e nenhum dos arquivos com.apple.recentitems.plist. Então, eu limpei a casa executando esses comandos em ~ / Library / Preferences /:
defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*
O defaults
comando diz cfprefsd
para remover todas as configurações desse domínio, o que deixa um arquivo .plist logicamente vazio de 42 bytes e um arquivo .plist.lockfile de 0 byte que o rm
comando remove.
defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm *LSSharedFileList.plist*
Menos óbvio, mas essencialmente o mesmo para todos os defaults
domínios com LSSharedFileList em seus nomes
find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm
Ainda menos óbvio, mas aparentemente crucial. Esse pipeline encontra todos os arquivos * .plist no diretório atual (que era ~ / Library / Preferences /,) verifica a validade de cada um com plutil -lint
, analisa os nomes de arquivos daqueles que não estão "OK", os envolve para proteger contra espaços incorporados e similares e remove todos eles. No meu caso, os arquivos * .plist inválidos eram todos os arquivos antigos de 0 byte para coisas que não podem ser executadas no El Cap, então eu tinha certeza de que não estava excluindo nenhuma informação real. YMMV !!
find . -size 42c -name "*plist" -delete
Isso varreu qualquer arquivo * .plist com 42 bytes de comprimento, o tamanho de um plist logicamente vazio em formato binário. Eu tinha alguns deles por aí e eles poderiam estar causando a reclamação sharedfilelistd
.
killall sharedfilelistd
Isso encerrou a instância de sharedfilelistd
execução em minha conta. O sistema reiniciou uma nova instância automaticamente. Não tenho certeza se isso era necessário, mas parecia prudente, pois acabei de eliminar um monte de informações do subsistema de preferências relacionadas à maneira antiga de fazer o que sharedfilelistd
aparentemente faz em El Cap.
OBSERVAÇÃO: Esses 7 comandos são a versão resumida do que eu fiz que fez sentido e teve efeitos, espalhados por 3 horas de bisbilhotando, testando e tentando encontrar informações sharedfilelistd
sem sucesso.
Também vale a pena notar que não há nenhum sudo
envolvido aqui, porque eu estava no meu próprio ~ / Library / Preferences /, manipulando meu próprio domínio de preferências. O menu Itens Recentes e, portanto, suas configurações são específicas do usuário, portanto, onde quer que essa configuração seja armazenada (nunca funcionou assim ...), também deve ser específica do usuário, e não algo que exija correção de raiz. Há uma resposta anterior que inclui uma limpeza maciça e inexplicável de permissão / ACL / flag, executada com sudo, que nem funcionou para o autor e pode causar sérios danos sistêmicos. Isso não é nada disso. Observe também que ele não requer logout, reinicialização, inicialização no modo de recuperação ou qualquer outra ação que possa causar interrupções.