Property list files

A list of preference settings for a given domain intersection is internally represented by a special type of data structure which is used throughout all parts of Mac OS X, a so-called property list. To be exact, the settings of the domain are represented by a dictionary, where the property keys of the domain settings become the dictionary keys, and the values for each setting become the respective dictionary values. For this reason, it is only natural that Mac OS X also uses its standard file format, the so-called property list files with the name extension .plist to save its copies of the preference domains internally. This way, the domain intersections contained in the preferences database are stored into persistent files, and the preference settings can keep their values and survive even if the applications or the operating system is shut down.

Understanding the difference between property list files and preference files

Mac OS X happens to use property list files to save the different domain intersections of the preferences database. In theory, it could use any other file format to do so, and predecessors versions of Mac OS X (e.g. NeXT OPENSTEP for Mach) in fact used other file types. As mentiond before, applications don't need to care how Mac OS X handles this, because they never access preference files directly. When an application asks for the value of a specified preference setting, Mac OS X makes sure to search and retrieve the value on behalf of the application. Although the application's process may indirectly open some of the plist files associated with the preference setting in question at that moment, the application doesn't really “know” this. Mac OS X lets the process indirectly call some of its internal features which perform the actual operations.

Depending on what domain intersection takes effect, Mac OS X will automatically generate the correct file name and folder name to search for available preference settings. For example, system-wide (all user) settings for the current computer will be stored in the folder /Library/Preferences with the application domain name as file name. Settings for the current user for all computers will be stored in the Library/Preferences subfolder of the user's private home folder, also with the application domain name taken as file name.

This means the persistent copy of the preferences database is stored into several hundred property list files, distributed among specific Library/Preferences folders. Remember that a preference domain is represented by a special type of property list, namely a list which has a dictionary with property keys at its top level. This means not all valid property list files will be valid preference files. Preference files are a special case of property list files and underlie certain restrictions. Mac OS X uses property list files for many other purposes as well. Property list files containing persistent parts of the distributed preferences database are just one special utilization where a specific class of plist files plays a role.

NOTE: When editing a property list file directly, PrefEdit will display if that file has the correct structure to be used as part of the preferences database or not. You can use PrefEdit to edit any property list file, not only preference files.

Understanding the difference between the live preferences database seen by applications and preference files

Applications use preference settings very often. For example, when you work with an application which opens a window containing some data arranged in a table, the application typically looks up

the preferred position of the window,
the preferred size of the window
the preferred order and widths of table columns,
the preferred sort order of entries listed in the table

and perhaps many other settings to silently let the application behave in the way you are preferring, reusing the remembered settings from the last time you used that window. This means there can be dozens of access operations to the preference database per minute. To handle this as efficiently as possible, each application keeps its own view of all domains it works with in its private memory space. Changes to the preference database at first only affect this in-memory copy. Only when Mac OS X has enough time to handle this in the background, or when the application explicitly requests to save its preference settings to persistent storage, Mac OS X will save the settings to all affected property list files.

This efficient technology has the following consequences:

You cannot be sure that an entry in the preferences database has been saved to the affected property list file yet! The live view on the preferences database does not necessarily match the representation in the files. Only after you have quit an application, you can be sure that Mac OS X had been forced to save all pending updates for the domain in question to persistent storage. Preference files and the preference database in memory are only guaranteed to be synchronized when the applications making changes to the affected domains are currently not running.
Each application has its own private view with its memory copy of the preferences database. If an application A modifes one of its preference settings, only that application will be seeing the change immediately. All other applications will only see this change after A has synchronized its settings with persistent storage and after those applications have been restarted, so that they have created their new in-memory views of the database!

Note that neither item (1), nor item (2) will affect applications under normal circumstances. If an application works with its own preference settings only, it does not matter if the in-memory database was synchronized with persistent storage yet. As mentioned before, the application does not need to know anything about persistent storage. Item (2) only becomes important if an application tries to re-read preference settings not owned by itself, but settings which are part of a different domain that had been modified.

However, both items are important for PrefEdit because PrefEdit is capable of accessing the preferences database and property list files containing preference entries at the same time. PrefEdit is also an application which reads preference settings which are owned by other applications.

For this reason you should always keep in mind that the preference settings you see in PrefEdit may neither be fully identical to the state of the database currently seen by other running applications, nor to the state of the database copy kept in preference files. PrefEdit will however correctly keep track of all changes and will warn you when conflicting updates may be in progress.

The following picture summarizes the relation of the preferences database as it is seen by applications and the preference files on disk:

Relation between preference database and persistent storage

Variations of the property list file format

Mac OS X currently knows three different ways a property list can be physically represented in a file:

a text file containing XML data, according to Apple's document type definition (DTD) for property lists. The DTD can be downloaded from http://www.apple.com/DTDs/PropertyList-1.0.dtd (Internet link).
a binary file containing the property list, encoded in a processor-independent way. Binary files are usually smaller than XML files with the same content.
a text file encoding the structure of property lists by different types of parentheses. This file format was used by predecessor versions of Mac OS X, for example by NeXT OPENSTEP for Mach.

The last file type is considered to be deprecated. It should not be used to create new plist files. For this reason, Mac OS X and PrefEdit can read but will never write such files.

Today's property list files should usually have names with the file extension .plist, no matter what format variant was used to store the list. However, PrefEdit will also accept files with the extension .dict, or with any other file name extensions. Mac OS X does not use any type or creator codes for property list files.

The current property list file format variations can be used fully interchangeably when storing preference settings and most other property lists. Mac OS X preferred XML lists to store preference settings in operating system versions prior to Tiger (10.4). As of Mac OS X 10.4 and later, Mac OS X has begun to store preference files in binary format, which will save storage space. As mentioned before, applications don't know anything about the plist files, so it doesn't matter which file format variation the current version of Mac OS X is using.