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 cfprefsdgerencia as informações reais de preferência e você precisa conversar com ele com o defaultsutilitá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 domainsuma 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 defaultscomando diz cfprefsdpara 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 rmcomando 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 defaultsdomí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 sharedfilelistdexecuçã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 sharedfilelistdaparentemente 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 sharedfilelistdsem sucesso.
Também vale a pena notar que não há nenhum sudoenvolvido 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.