Я зіткнувся з цим сьогодні на місячному iMac. Єдине, що не свідомо в цьому, - це мій обліковий запис, який було тиражовано на 5 машинах та 12 основних версіях MacOS, використовуючи програму Migration Assistant, коли це можливо, залишаючи її трохи в ~ / Бібліотека / Налаштування /. На жаль, в останніх версіях 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. Тому я очистив будинок, запустивши ці команди всередині ~ / Бібліотека / Налаштування /:
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 у поточному каталозі (який був ~ / Бібліотека / Налаштування /,) перевіряє кожен на дійсність plutil -lint
, аналізує назви файлів, які не є "ОК", призначає їх для захисту від вбудовані пробіли тощо, і видаляє їх усі. У моєму випадку недійсними * .plist файлами були всі антикварні файли 0 байтів для речей, які так чи інакше не можуть працювати на El Cap, тому я був впевнений, що не видаляю фактичної інформації. YMMV !!
find . -size 42c -name "*plist" -delete
Це змістило будь-які * .plist файли, довжиною 42 байти, розміром з логічно порожнім списком у двійковому форматі. У мене було декілька тих, хто звисав, і вони, можливо , викликали скаргу sharedfilelistd
.
killall sharedfilelistd
Це припинило примір sharedfilelistd
запуску мого облікового запису. Система автоматично перезапустила новий екземпляр. Я не впевнений, що це було потрібно, але це видалося доцільним, оскільки я щойно видалив купу інформації з підсистеми уподобань, яка була пов'язана зі старим способом робити те, що, sharedfilelistd
мабуть, робить у El Cap.
ПРИМІТКА. Ці 7 команд - це скорочена версія того, що я зробив, що мало сенс і мало наслідки, розкидані на три години, копаючись і тестуючи і намагаючись знайти інформацію sharedfilelistd
безрезультатно.
Варто також зазначити, що тут немає ніякого sudo
участі, бо я був у власній ~ / Бібліотеці / Вподобаннях /, маніпулюючи власною сферою уподобань. Меню Останні пункти, а отже, і його налаштування, залежать від користувача, тому де б це зберігалося (ніколи не працювало так), повинно бути і певне користування, а не те, що вимагає кореневого виправлення. Існує попередня відповідь, яка включає незрозуміле масове видалення дозволів / ACL / прапор, запуску з sudo, що навіть не спрацювало для автора, і може призвести до серйозної системної шкоди. Це нічого подібного. Також зауважте, що для цього не потрібно виходити з системи, перезавантажуватися, завантажуватися в режимі відновлення або робити щось інше, що може бути руйнівним.