![]() Can also quit the process from Activity Viewer, or killall cfprefsd. Safari preferences are stored under the user domain, so the user-specific daemon is the one that needs a reset when files change. There exists a cfprefsd daemon for every logged in user, running under that user’s privileges, as well as a root-owned one. When Safari is reset manually from the filesystem, or if the plist files are edited, cfprefsd must be reset as well. This does not mean there are hidden Safari preferences somewhere that you haven’t found, though you might think this at first. When the app is opened again, the cached version takes precedence, and is re-written out to disk, clobbering the restored versions. However if the preference files are changed or edited directly, this change is not propagated to the preference cache daemon. The defaults command has been modified to operate with this daemon, so if you had been working with preferences from the command line (as I have been), the changes have been transparent. Instead of applications pulling their preferences from XML files on disk at launch, it requests this from the daemon instead. Presumably to save energy, OS X Mavericks caches application preferences (in RAM?) using a daemon called cfprefsd. It turns out there were two separate obstacles. 30 mins of reviewing useless forum posts later, I pieced together a multi-stage solution. Increasingly desperate, I started to trace filesystem accesses using fs_usage. ![]() Imagine my surprise when nothing became restored, and all my Safari extensions (installed from the extension store or custom-built by me) disappeared. After resetting to confirm some issues have disappeared, I moved some files from backup to original locations. I then removed ~/Library/, ~/Library/.plist, ~/Library/Safari, and ~/Library/Caches/Safari, ~/Library/Cookies. This is pretty important if you don’t want to blow up Safari bookmarks (at the very least) across all Apple-manufactured, iCloud-compatible devices. I’ve done this many times before.įirst I turned off iCloud sync, having been bitten by sync propagation of experimental changes in the past. Had the brilliant idea of setting Safari preferences aside, thus resetting Safari to factory state, and then divide-and-conquer by restoring parts of the settings until the problem recurs. I deduced there was some kind of corrupted stored state, whether it was a cookie or localstorage issue. Had some issues where certain websites were behaving differently under private browsing mode than normal browsing mode. restoring the list of installed extensions - which, incredibly, is NOT stored in the deceptively named .plist, but in the login.keychain.This where a lot of people get stuck in general, judging by Google results when they replace preference files and find that their changes aren’t being reflected, it leads them into a wild goose chase for “hidden preference files” for Safari, when the answer lies in a simply yet utterly non-obvious background daemon. resetting the preference cache daemon, cfprefsd so that preference changes can be reflected in a running system.replacing the actual preference files, scattered around the system in ~/Library/Safari, ~/Library/Preferences, ~/Library/Caches, and hopefully remember to have turned off iCloud, or otherwise see changes being clobbered by iCloud sync (or, worse yet, having experimental changes reflected all across a network of Mac and iDevices).unhiding the Library directory, because clearly we’re all Windows babies who cannot be trusted to see where application preferences are stored.But no, an incredible amount of effort is now required for a simple task: Considering that preferences in OS X have always been stored in XML-based preference lists, you would think (as in previous operating systems from 10.0 to 10.7) taking the relevant preference files and replacing the unwanted new ones in ~/Library/Preferences would be enough. ![]() It turns out that after Mavericks, Safari is incredibly resistant to conventional methods of preference file backup and restoration. Takes all of 2 minutes, and years ago, I had already wrote a shell script to do exactly that. I have done this many times before on older OS X versions, without incident - simply pull the various preference files such as from backup and replace the damaged/unwanted ones. Recently I had the misfortune of having to restore some Safari settings from backup, on OS X 10.9 Mavericks. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |