Я столкнулся с этим сегодня на месячном iMac. Единственная вещь, которая не совсем свежа в этом, - это моя учетная запись, которая была реплицирована на 5 компьютерах и 12 основных версиях MacOS с помощью Migration Assistant, когда это возможно, что оставило немало ошибок в ~ / Library / Preferences /. К сожалению, в последних версиях Apple усложнялась эффективная очистка этого каталога путем удаления файлов, потому что он cfprefsdуправляет информацией о реальных предпочтениях, и вам нужно с ней приятно поговорить с defaultsутилитой.
В любом случае, мне нравится, что каждый раз, когда я пытаюсь изменить предпочтение, я получаю последовательность записей в журнале:
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
Кроме того, оба defaults domainsи несколько десятков файлов в настройках говорят мне, что большинство приложений с соответствующим доменом по умолчанию, таким как com.example.appname, также имеют домен по умолчанию, например com.example.appname.LSSharedFileList, который содержит списки недавно использованных файлов. За исключением того, что они не были недавно использованы файлы вообще. Ни один из файлов * .LSSharedFileList.plist не изменился со времени моей миграции со старой машины Yosemite, и ни один из них не имел com.apple.recentitems.plist. Поэтому я убрал дом, выполнив эти команды внутри ~ / Library / Preferences /:
defaults delete com.apple.recentitems
rm com.apple.recentitems.plist*
defaultsКоманда говорит , cfprefsdчтобы удалить все настройки в этой области, которая оставляет 42-байтовый логически пустую .plist файл и 0 байт .plist.lockfile файла , который в rmкоманде удаляет.
defaults find LSSharedFileList |grep 'keys in domain .*LSShared'|cut -d"'" -f2 |xargs -L1 defaults delete
rm *LSSharedFileList.plist*
Менее очевидный, но по сути одно и то же для всех defaultsдоменов с LSSharedFileList в их именах
find . -name "*.plist" -print0 |xargs -0 -L1 plutil -lint |grep -v ': OK$'|cut -d: -f1|sed 's/.*/"&"/' |xargs rm
Еще менее очевидно, но, по-видимому, важно. Этот конвейер находит все файлы * .plist в текущем каталоге (который был ~ / Library / Preferences /,), проверяет каждый на предмет допустимости plutil -lint, анализирует имена файлов, которые не являются "OK", ставит их в кавычки для защиты от встроенные пространства и тому подобное, и удаляет их все. В моем случае все недействительные файлы * .plist представляли собой 0-байтовые античные файлы для вещей, которые в любом случае не могут работать на El Cap, поэтому я был уверен, что не удаляю какую-либо фактическую информацию. YMMV !!
find . -size 42c -name "*plist" -delete
Это уничтожило все файлы * .plist длиной 42 байта, размером с логически пустой список в двоичном формате. У меня было несколько таких людей, и они могли быть причиной жалобы sharedfilelistd.
killall sharedfilelistd
Это прервало случай sharedfilelistdзапуска под моей учетной записью. Система автоматически перезапустила новый экземпляр. Я не уверен, что это было необходимо, но это казалось благоразумным, поскольку я только что удалил кучу информации из подсистемы предпочтений, которая была связана со старым способом делать то, что, по- sharedfilelistdвидимому, делает в El Cap.
ПРИМЕЧАНИЕ. Эти 7 команд являются сокращенной версией того, что я сделал, что имело смысл и дало результаты, разбросанные по 3 часам возни и тестирования, а также попытки найти информацию sharedfilelistdбезрезультатно.
Стоит также отметить, что здесь нет никакого sudoучастия, потому что я был в своем собственном ~ / Library / Preferences /, манипулируя своим собственным миром предпочтений. Меню «Недавние элементы» и, следовательно, его настройки зависят от пользователя, поэтому, где бы эта настройка ни хранилась (никогда не получалось…), она также должна зависеть от пользователя, а не от того, что требует root для исправления. Существует предварительный ответ, который включает в себя необъяснимую массовую очистку разрешений / ACL / флагов, запускается с помощью sudo, которая даже не работает для автора и может нанести серьезный системный вред. Это не так. Также обратите внимание, что для этого не требуется выходить из системы, перезагружаться, загружаться в режиме восстановления или делать что-либо еще, что может привести к сбоям в работе.