Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've read a few different troubleshooting articles and Q&A's where the culprit is a corrupted preference file for an application or process. Typically the solution is to delete the bad preference file and allow a new, default preference file to be spawned upon restarting whatever software was misbehaving.

How does a preference file become corrupted? Is this simply a low-level read/write error, or is there a higher level error occurring in some cases? Is it just malformed or misspelled XML?

I believe plutil could tell you if there's a syntactical error with the file, but again, how was the error introduced? I'm unclear on the usual source for these corrupted files. Thanks.

share|improve this question

It can be caused by a great number of things, but I believe the most common cause is where the file is being written to, and the application terminates before it's finished writing the file. This could be caused by system overheads being too great for a successful write at the time.

Hardware errors with the hard disk, or memory could also cause data errors, but I would imagine these would be the least of your problems by this time.

share|improve this answer
I'm skeptical. If that is ever the case, the app must have been very poorly written, since it takes literally 2 extra words to avoid this obvious bug. Apple's sample code for writing a plist uses the method -writeToFile:atomically:YES ("the data is written to a backup file, and then -- assuming no errors occur -- the backup file is renamed to the name specified"). The POSIX rename() function guarantees the file will exist "even if the system should crash in the middle of the operation". – Ken Aug 30 '12 at 2:43

I would bet that in almost every case, there is nothing syntactically wrong with the plist file. Apple's functions for loading and saving plist data get a lot of attention and a lot of use. Almost every bug has surely been found and fixed by now.

(Consider that plists are used for all kinds of things, like drag-n-drop and the clipboard, sandbox permissions for launching apps, the user interfaces for every app, and even which icon to display in the Finder. It would be incredible if there was a bug in the plist-writing code which just happened to screw up preference files for some apps, but not any of these other things!)

An app's preference file (plist) is simply storing some of its in-memory data structures on disk. So if the app has a bug that causes something to be set incorrectly, it gets saved.

Often when an app starts misbehaving, you can simply quit it and restart. That resets many parts of it, and may fix the problem. Preference files are reloaded from disk, though, so if the affected part of the app was saved in a persistent preference, restarting the app will have no impact: the bad value will just get loaded again. That's when deleting the preference file can help. It's like restarting the app, but for things that got saved.

These things can happen because programmers assume that the data their app has is correct. If a color can be chosen only by the user clicking on a standard color wheel control, they probably don't do any extra work to verify that it's correct before using it. (In comparison, an app like Safari does a ton of extra work verifying everything, because it loads and runs files straight off the internet.)

The upside is that it's almost always correct, and it's far easier if you assume that internal values are correct. The downside is that if a bad value sneaks in somehow (like the user did something totally unexpected), things can go haywire until everything is reset.

share|improve this answer
That's interesting. You're saying the problem is generally app-specific and has to do with a bug or oversight that allows bad values to be set and not verified before later use, not with any read/write or general handling of the plist. It still strikes me as strange though that something as common (and official) as Dock (…) would have a problem, though perhaps that is an exception and really is a read/write error. – wxs Aug 31 '12 at 3:51
walker: If somebody has one of these corrupt Dock plist files, it's easy to check. My money is still on a bug in the app (System Preferences or Dock), not the plist code. – Ken Sep 4 '12 at 21:40

As a tech-challenged senior citizen, I found my iTunes Preference File was corrupted and caused the licensing agreement to come up every time I opened iTunes. Plus, all my preferences had to be reset. I believe the above answers are correct, as just before I had this issue, I was forced to do forced shutdowns of my computer (electrical issues in the area) and rebooting/half rebooting several times. The applications terminated before instructions/writing was complete. But the fix to spawn a new iTunes preference file was shown online and very easy to do. It fixed the problem.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.