Multiple copies of the same .plist name in preferences folders

When most programs in OS X save preferences and settings, they do so by using standard property list files (.plist), which are either ASCII or binary-encoded XML files that have a naming convention of "domain.developer.application.plist" (e.g., "com.apple.iTunes.plist") though some subcategory preference files may exist such as "com.apple.iTunes.eq.plist" for the iTunes equalizer settings. These files are generally stored in the Preferences folder that is within the user's library, but may also be stored in the global library at the root of the hard drive.

While only one copy of a preference file should exist for a specific application, if you look in the various preferences folders you may find multiple copies of specific files, though the copies will usually have a random seven-character alphanumeric string tacked on to the end of the name, will have a generic document icon, and will be "Zero KB" in size.

This may cause some confusion for people, especially when trying to delete a specific preference file to troubleshoot application problems. Some people have wrongly guessed that these are caches, or that they are somehow actively used by the associated application and as such have avoided tampering with them. In truth, however, these files are just leftover temporary files from the process used to save plists.

When you alter an application's settings, the preferences file for the application is not directly written to. Instead, the underlying programming for saving property lists will first write the files to a temporary file that has a unique string of characters appended to its name that associates the file with that particular "save session." The process will then remove the old preferences file and rename the temporary file to remove the trailing character strings so it becomes the active preference file for the program.

This type of process helps prevent property list corruption in the event of a program crash or other malfunction when the settings are being saved. It happens when you specifically apply settings, but also may happen regularly as you use a program, since the program will refresh the preference file with odd details such as the last documents opened, window positions, and other miscellaneous settings.

While the file rename should result in only one final file on disk, an apparent bug in the plist write process sometimes allows the directory entry for the file's old name to remain. This could be due to an error in how the file's various permissions and extended attributes are handled when it is being created and written to. However, regardless of the specifics this error results in the slow and random accumulation of these files over time.

Ultimately Apple will have to tweak the plist write process to prevent multiple directory entries for these files from staying behind, but overall they are just residual temporary entries that do not contain any data, and can be removed without harming a thing. Being stashed away in the preferences folder they will likely not interfere with your work, and you can easily remove them by sorting the contents of your preferences folder by size and removing all of the 0 KB files.

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.