Могу поспорить, что почти в каждом случае нет ничего синтаксически неправильного в файле plist. Функции Apple по загрузке и сохранению данных plist привлекают большое внимание и широкое использование. Почти каждая ошибка наверняка найдена и исправлена.
(Учтите, что списки используются для всех видов вещей, таких как drag-n-drop и буфер обмена, разрешения для песочницы для запуска приложений, пользовательские интерфейсы для каждого приложения и даже какой значок отображать в Finder. Было бы невероятно, если бы в коде написания списков ошибок произошла ошибка, из-за которой испортились файлы настроек для некоторых приложений, но не для всех остальных!)
Файл настроек приложения (plist) просто хранит некоторые из его структур данных в памяти на диске. Поэтому, если в приложении есть ошибка, из-за которой что-то устанавливается неправильно, оно сохраняется.
Часто, когда приложение начинает плохо себя вести, вы можете просто закрыть его и перезапустить. Это сбрасывает многие его части и может решить проблему. Файлы настроек перезагружаются с диска, поэтому, если уязвимая часть приложения была сохранена в постоянном предпочтении, перезапуск приложения не окажет никакого влияния: неверное значение просто загрузится снова. Вот когда удаление файла настроек может помочь. Это как перезапуск приложения, но для вещей, которые были сохранены.
Это может произойти, потому что программисты предполагают, что данные их приложения верны. Если цвет может быть выбран только пользователем, щелкающим по стандартному элементу управления цветовым колесом, он, вероятно, не выполняет никакой дополнительной работы, чтобы проверить его правильность перед использованием. (Для сравнения, такое приложение, как Safari, выполняет кучу дополнительной работы, проверяя все, потому что оно загружает и запускает файлы прямо из Интернета.)
Плюс в том, что это почти всегда правильно, и гораздо проще, если вы предполагаете, что внутренние значения верны. Недостатком является то, что если какое-то плохое значение просачивается как-то (как пользователь сделал что-то совершенно неожиданное), все может пойти не так, пока все не будет сброшено.
-writeToFile:atomically:YES
(«данные записываются в файл резервной копии, а затем, при условии отсутствия ошибок, файл резервной копии переименовывается в указанное имя»). Функция POSIXrename()
гарантирует, что файл будет существовать «даже в случае сбоя системы в середине операции».