One way to tell genuine Question and Answer columns from those that are fabricated by the writer is whether there is a steady trickle of issues over preference list, or .plist, files. Although most of us try not to overburden published collections with them, they have been a constant problem for users since the first beta release of OS X: one of its most persistent running sores.

The idea is simple. Anything – particularly apps – which needs to store persistent settings, notably those determined in its Preferences dialog, does so in files which are stored in an appropriate Library/Preferences folder. These preference list files, assigned the filename extension .plist, are structured XML dictionaries, listing the values of various properties.

Here, for example, is MarsEdit’s Preferences dialog, which lets me configure it as I wish, then stores those settings in the form of XML properties in the file shown below (viewed using PlistEdit Pro).

It’s a simple design, and you might wonder what could possibly go wrong, to generate all those reader questions. The most common answer is that somehow the property list file becomes corrupted, and once so damaged, the app seems incapable of writing out any new settings. So you open the app, change the preferred fonts, say, then the next time that you come to use that app, the fonts have reverted to their previous state.

The classic response from the Q&A columnist is to locate the property list file, trash it, then configure the app’s preferences again, expecting that they will then persist as they should.

Over all that time, it has puzzled me that those writing apps seem to have been unable to overcome such a simple problem, of writing out changed preferences reliably. But the problem continues to afflict apps, and almost everything that can be set in OS X as well.

Neither are the solutions as simple as they should be. The first problem now is knowing where to look for the preference list file. Originally, they were all supposed to be stored in ~/Library/Preferences, which provides for individual settings for each user. Then along came the App Store, and brought its containers, intended to keep such things in a sandbox, so you’re now supposed – for App Store apps only – to look first in ~/Library/Containers, which will probably lead you through aliases back to the normal location. A few turn up instead in ~/Library/SyncedPreferences, when those settings are synchronised with other systems, and some just get buried somewhere else.

Preference files are also supposed to be named according to a standard convention, of the app’s signature, a sort of reversed URL, such as com.red-sweater.marsedit.plist. This makes life a bit more complicated, as you have to remember that MarsEdit is developed and sold by Red Sweater. Not that all apps follow that convention either.

Apple’s preferences are a serious mess, with many residing in files with names which you would not associate with those settings, and in odd locations: many of your Mac’s most important settings are now to be found in /Library/Preferences/SystemConfiguration, which is why you can’t find them in the traditional locations of ~/Library/Preferences and /Library/Preferences. And just to make life easier, most major releases of OS X rejig which settings are stored where, so an answer for Mountain Lion would probably be quite different to the corresponding solution for El Capitan.

Some settings are duplicated, because there need to be user-agnostic values and per-user ones. A good example of this is the default keyboard: that employed before you log in is stored in /Library/Preferences/com.apple.HIToolbox.plist, but once you have logged in, it is ~/Library/Preferences/com.apple.HIToolbox.plist which prevails. If either of those becomes damaged, you could find yourself having an unwanted default keyboard thrust upon you.

There are some more devious ways of working around some of the more frustrating problems which can arise. Keyboard and other settings which are normally configured during installation of OS X can sometimes be ‘refreshed’ by pretending that your copy of OS X is only now being run for the first time. You can do that by deleting the hidden file .AppleSetupDone which signals to OS X that it has been fully configured, using a command like
sudo rm /var/db/.AppleSetupDone
in Terminal. You may also be able to do it by running Setup Assistant, which is found in /System/Library/CoreServices. These are likely to undo most of your other key settings, so should be used only as a last resort.

But the strangest thing about all these problems is that the user is never informed about any of them – you have to guess what has gone wrong, and how to fix it. Even apps which are very good about informing you if there are problems saving a document seem not to care a hoot when they can’t save your changed preferences. Conspiracy theorists will no doubt claim that a deal has been done with the Secret Brotherhood of Mac Q&A Writers. But I really couldn’t comment.