Preferences Files: The Complete Story (Part V); How .plist files become corrupt and troubleshooting the results

Preferences Files: The Complete Story (Part V); How .plist files become corrupt and troubleshooting the results

Ted Landau

Welcome back to the tutorial series that covers everything you ever wanted to know about preferences (.plist) files. So far, we have explored what .plist files are, how to interpret the content of .plist files, and how to edit these files (including working with "hidden" settings). For all the details, see Parts I & II, Part III, and Part IV. In this part, we take a slight detour and explore what is probably the most common thing people do with .plists files: trash them!

PART V: What's the trouble with Preferences files?

Q. Why are preferences (.plist) files so often implicated in application crashes and other similar trouble?

A. Every time you modify and save a file, the file is rewritten to your drive. And each time a file is written to a drive, there is a chance (a very small chance, but not an insignificant one) that the file is written incorrectly?with the result that you wind up with a damaged/corrupted file. The laws of probability tell us that even an unlikely event becomes likely given enough opportunities. To put it another way: the odds may be fairly low that you will lose your luggage the next time you fly; however, if you are a businessperson who flies twice a week on average, the odds that your luggage will get lost at least once in the next couple of years is much higher.

And so it is with .plist files. They are among the most frequently modified files on your drive. Even if you don't make any changes to an application's preferences settings, its .plist file may still get modified on a regular basis. For example, there may be a property in the file that records the last time the application was launched. If so, the application's .plist file gets updated at least as often as every time you launch the application.

The net result is that, like lost luggage for a frequent flyer, most Mac users can expect to confront a damaged .plist file eventually. A damaged .plist file, in turn, will likely lead to other, more obvious, symptoms. These can range from a feature of the application that no longer works correctly to the application crashing on every launch attempt.

Q. OK. Suppose I have a problem with an application that I suspect is caused by its .plist file. What can I do about it?

A. The simplest solution is to remove the application's .plist file from its Preferences folder location. When you do this, a new default version of the .plist file is created in the Preferences folder. Presumably, this new file no longer contains the corrupted data of the original file, thereby eliminating the problem. To accomplish this, do the following:

  1. If currently open, quit the problem application. Among other benefits, this eliminates the possibility that corrupted data from the .plist file is held in RAM while the application is open and might be copied back to the new default .plist file when you quit the application.

  2. Locate the application's .plist file. Typically, it is in the Library/Preferences folder of your Home directory and its name will include the name of the application (such as for the iPhoto application). To quickly find it, open the Preferences folder and type the name of the application in the window's Search box.

    Tip: Still having trouble locating the .plist file for a given application? Try AppZapper; it lists all files related to a selected application (including its .plist file) and allows you to move any or all of the files to the Trash.

  3. Move the relevant .plist file to the Trash.

  4. Launch the application. This creates a new default .plist file. Check to see if the problem has vanished.

  5. If the problem is gone, you can assume that the removed .plist file was the cause. You can now empty the Trash to permanently delete the file. However, if the problem persists, the .plist file was not the cause. In this case, quit the application and return the .plist file from the Trash to its prior Preferences folder location. When you do this, you will be asked if you want to replace the newer .plist file that is already there; say "Yes". This way, you don't unnecessarily lose any customized settings stored in the original file.

  6. If you wound up trashing the original file, you will now have to recreate any custom preferences settings that were lost. This is because the new default file, by definition, does not contain any changes that you made to the original file. In the best case, this means spending only a minute or so in the application's Preferences dialog to set things up again. In the worst case, you may have settings that are all but impossible to reconstruct.

    For example, in the file, the persistent-apps property contains the list of all the applications, folders and documents that you added to the Dock as well as where in the Dock all the icons are positioned. Unless you have a photographic memory, made very few changes from the Dock's default set, or took a snapshot of the Dock before you switched .plist files, you may never be able to get the Dock back to exactly how you previously had it. Unfortunately, that is the price you need to pay for eliminating a corrupt file.

    Similarly, if you added any hidden properties to a .plist file, you may have trouble remembering what they were.

    Tip: To save custom settings that might otherwise be difficult to recreate, you can copy the desired properties from the old file and paste them into the new file (assuming that the data you want to save is not the corrupted part of the file!), replacing existing properties of the same name as needed. To do this, use a utility such as Pref Setter. [Doing this assumes you are comfortable directly modifying the content of .plist files and can identify which properties you want to save. Background on such matters was covered in previous parts of this tutorial series.] [Continued...]

Note: There may be a few files in your Preferences folder that you do not have permission to read, edit or replace. This is typically because the applications that use these .plist files run as the root user; their .plist files are thus owned by the root user as well. Disk repair utilities often fall into this category. You should be able to end run around these restrictions by giving your admin password in the dialog that appears when you attempt to modify, move or replace the .plist file.

Q. Is it always as easy as you just described to locate the potentially corrupt .plist file linked to a problem application?

A. Unfortunately, no. Here are some possible complications:

  • There may be more than one .plist file that contains the name of the application?and only one of them may be the cause of your problem. For example, there are several .plist files with "iTunes" in their name.

  • A problem may be linked to an activity rather than an application. For example, if a problem affects printing in several applications, you probably want to check out all the .plist files that begin with "".

  • An application may use a .plist file that does not include the name of the application. For example, almost all Web browsers, in addition to whatever other .plist files they access, also use the file.

  • The relevant .plist file may be located outside the ~/Library/Preferences folder.

There is no easy rule as to what to do in these cases. You will either have to do some research (such as a Google search) to determine the name and location of the potential culprit file or use a utility to assist you (such as Printer Setup Repair for printer related problems).

Q. Before attempting to deal with these complications, isn't there at least some way to first determine whether or not any .plist file is the possible cause of the symptom?

A. Yes. There are several approaches you can take here:

  • Remove the entire Preferences folder from your Library folder. Now check to see if the problem vanishes. If it does, you at least know that some file in the Preferences folder is the cause. It may take some trial-and-error to figure out which one it is, but at least you know you are not wasting your time by trying.

  • An even more general approach is to create a new account (via the Accounts System Preferences pane) and log in to that account. Once logged in, check to see if the problem is gone. If it is, it is almost certain that the cause of the problem is a file in your original Home directory (most likely in the Library folder) that does not exist (or is not corrupted) in the new account. It could be a .plist file. But it could also be a font, or a file in the Application Support folder or one of several other Library folders. Again, you may have some work to do to determine which file is the culprit one. But at least you know the problem is not with the application itself or with Mac OS X system files?which means you probably do not need to reinstall the application and/or Mac OS X to fix the problem.

  • You can directly check on the integrity of .plist files. You can do this with a Unix program (run form Terminal) called plutil. [Yes, this is the same program described earlier in this series for converting binary .plist files to text files.] However, I recommend instead using a graphical user interface (GUI) to plutil called Preferential Treatment. In either case, what these tools do is check whether or not a .plist file uses the correct XML syntax (recall that .plist files are written in XML).

    To use Preferential Treatment: After launching the program, click the Lock icon in the upper right of the window that appears. Enter your admin password; this prevents reports of errors that simply mean you do not own the .plist file (a potential issue mentioned earlier in this article). Next, click the Check User Preferences button and wait for the results to appear. If the application flags one or more files as having a problem, these would be a good place to start your search for the culprit.

    Figure 1. Preferential Treatment.

    However, Preferential Treatment has its limits. In particular, it will not detect errors that do not affect the file's syntax. For example, it cannot check if there is a spelling error in the name of a file listed as a value for some property. This means that even if Preferential Treatment reports that all is okay with a file, there may still be a non-syntax-related problem with the file.

    Conversely, even if Preferential Treatment reports a problem, it does not necessarily mean you need to fix anything. For example, if it reports an error that says a file is an alias, you can typically ignore this (BBEdit and TextWrangler create such alias files).

    Despite these caveats, if you suspect .plist file trouble and are uncertain as to which file is the cause, running Preferential Treatment is worth a shot. It is simple to do and has no negative side-effects.

    Note: Preferential Treatment can also check for problems with System Preferences (located in the main /Library/Preferences folder). I'll be talking more about .plist files in that location in the next article of this series.

Q. I've read that Tiger (Mac OS X 10.4) includes a new feature for troubleshooting .plist files. True?

A. You are correct. Recognizing the importance of removing .plist files as a troubleshooting technique, Apple equipped Tiger with a way to do it automatically, without the user needing to know exactly what is going on. However, it only works for those cases where the .plist file problem leads to an application crash that, in turn, results in the appearance of the "unexpectedly quit" dialog. I covered this topic at length in a previously posted mac.column.ted column ("Tiger's new and improved 'application crash' dialogs"). In brief, when you use the dialog to relaunch a crashed application, on the second relaunch (when you click the Try Again button), Tiger performs a "safe relaunch."

Figure 2. The "unexpectedly quit" dialog with the Try Again button.

In this case, the application launches with a new default .plist file instead of the older potentially corrupt one. If the crash no longer occurs, you can permanently shift to the new .plist file by selecting to "Use new settings" from the dialog that appears when you select to quit the application. Otherwise, you can keep the original settings instead. [Note: Later versions of Mac OS X 10.4 use a slightly modified version of the "New Settings" dialog than the one that appears in the mac.column.ted article. In particular, the buttons now read "Use new settings" and "Use original settings," rather than "Yes" and "No."]

Q. What if a corrupt .plist file is causing a crash at startup? How can I delete the file if I can't get my Mac to startup?

A. Good question. First, some good news: This is a rare event. Further, it is very very unlikely to happen as a result of a .plist file in your Home directory (which is where most of the relevant .plist files reside). That's because these .plist files can't even potentially have an effect until after you login to your account?at which point a crash is unlikely to bring down the entire system. It is much more likely to happen due to a .plist file located outside of your Home directory.

To keep things simple, I will assume that you know the name and location of the file you want to delete (for example, because you learned about potential problems with the file from searching the Web); what you need to know now is how to work-around the startup crash so you can delete the file. Here's are several suggestions:

  • Try a Safe Boot by holding down the Shift key at startup. This disables a number of OS X features that might be contributing to the crash (see this Apple Knowledge Base article for more details). If this works, locate the suspect .plist file and delete it. Enter your admin password, if requested.

  • If you have a second bootable hard drive (or even a separate bootable partition of your default drive), boot from it. If this works, locate the suspect .plist file and delete it.

  • Boot from a Mac OS X Install CD/DVD. An obstacle with this solution is that you cannot get to the Finder to delete the file. However, you can launch Terminal (accessed from the Utilities menu). From here, assuming you know the relevant Unix commands, you can locate the file and remove it. For example, to remove a file called totaldisaster.plist located in the Preferences folder of the main Library folder at the root level of a drive named Nemo, do the following:

    1. From the Terminal window prompt, type: cd /Volumes/Nemo/Library/Preferences.
    2. Type: ls. Check the output to confirm that the file you want to delete is there.
    3. If it's there, type rm totaldisaster.plist.
    Alternatively, you can instead use the mv command to rename the file or move it to a different location (thus deactivating the file). This should solve the crash problem while still allowing you to access the file, if desired, after you reboot.

  • If a Safe Boot fails, and you don't have ready access to an alternative startup drive or disc, you can start up in single-user mode. To do so, hold down Command-S at startup. This directly dumps you into a Terminal-like environment from which you can delete the problem file, once again using Unix commands. See this Apple Knowledge Base article for a "real-life" example of deleting .plist files via single-user mode to solve a blue-screen crash at startup.

That wraps up things up for today. See you soon for the next installment of the series.

Ted Landau is the author of Mac OS X Help Line: Tiger Edition, now also available as a PDF download, where you can learn all the dirt on .plist files and everything else related to troubleshooting Mac OS X.

Like what you've found in this tutorial? Get more troubleshooting guidance (updated daily) by subscribing to MacFixIt Pro.

  • More from Tutorials

    Join the discussion

    Conversation powered by Livefyre

    Don't Miss
    Hot Products
    Trending on CNET


    Up for a challenge?

    Put yourself to the real tech test by building your own virtual-reality headset with a few household items.