Not all plists are created equal: Be cautious with what you delete
Since preferences are recreated by applications upon launch, the recommendation to remove preference files is relatively harmless; however, do not misinterpret these recommendations to mean any plist may be treated this way safely.
In the process of troubleshooting poor application performance, the removal of preference files is often an easy remedy. In Mac OS X, preference files are usually saved in the property list format, which are identified by their .plist suffix. Since preference files are recreated by applications upon launch, the recommendation to remove preference files is relatively harmless; however, do not misinterpret these recommendations to mean any plist may be deleted safely.
Not all plists are preference files!
The property list format is just a specific use of XML which stores several types of information (strings, numbers, Boolean values, dates, and data arrays), and is formatted with an identifier tag followed by a value for that identifier. Apple adopted this format this for use in OS X in part as a replacement for the missing resource forks that files used to have in the old Mac OS, and has expanded its use to multiple areas of the operating system.
While the property list is the default format for preference files in OS X, the format is also used for numerous other setting and configuration files, including resource management in application bundles and for holding application arguments for launch daemons. These files cannot be easily replaced if removed.
Generally, only the plist files that are in a "Preferences" folder are those that can be removed without removing functions to either the system or applications. Unless you know exactly what you are doing, others should be left where they are and managed through utilities and commands that interact with them.
In browsing through various forums, I've seen a number of suggestions where people have been deleting system files to fix problems. An example of this is this Apple Discussion thread, where the recommended fix for a problem was to remove one of the coreaudio daemon property lists. While this has prevented the problem, in doing so, it also prevented the audio subsystem from launching properly, resulting in muted applications that use the coreaudio technologies. People have then tried to restart their broken audio systems by running the "launchctl" manager for the launch agents, not realizing that this utility requires the deleted property list to properly launch the daemon and restore audio function.
Instead of removing the coreaudio launch daemon property list, the users could have disabled it by using the "launchctl" command "sudo launchctl stop com.apple.audio.coreaudiod", or use similar commands to unload the coreaudio plist for troubleshooting. Unfortunately, the common suggestion to just remove a plist file seems to have instilled a notion that any plist file can be removed. This is not the case, and I strongly recommend that people research the uses of a specific plist before tampering with it, especially if the plist is not in a preferences folder.
Questions? Comments? Post them below or email us!
Be sure to check us out on Twitter and the CNET Mac forums.
