For the longest time I've been having issues with audio keyframes inserting themselves where I don't want them as opposed to where the playhead is. Deleting my preference files fixed this. But now I am once again editing audio in a 5,1 surround project and with audio inside of compound clips, so the keyframes have started to do the same nonsense again. Now I will have to once again delete the preferences file and reset everything back to the way it was, which to say is quite annoying.
I wonder if it is possible for Apple to make it so the preferences file doesn't, you know, get corrupt. Am I asking too much of Apple?
You are not only asking too much from Apple, you are asking too much from anyone who develops an operating system or any other kind of software. Juts google "corrupt preference file" and you will see posts about corrupt preference files in Windows, Mac, and Linux as well as in any kind of software including Google apps and the entire Adobe CC Collection.
This article explains why preference files are bound to get corrupt and shows you how to repair/reset preference files without having to enter all your prefs again:
Personally, I reset my FCP preference files once a week, even if I have no issues, because this is the app I use most intensively. I simply relaunch with OPT+CMD and reset my prefs manually because there aren't many boxes to tick and the whole process only takes 30 seconds. If you have issues with an app that can have very convoluted preference settings (like most Adobe apps), your can swap the corrupt pref file with a fresh one that you have saved. This is explained in the article.
People regularly report systems slowing down without any apparent reason. In many cases, this is due to corrupt user preferences in the OS. That's why I also regularly refresh these preferences to avoid any sudden performance issues during an edit. Resetting user preferences on the OS is much more complex as it often requires creating a new user and entering all your settings manually again. But there is also a quicker solution for this:
@Redifer, that is a logical question. Ideally FCP preferences should not require resetting, at least not frequently. Yet it's a common required procedure.
The simple answer is FCP preferences are stored in a .plist file in ~/Library/Preferences, not in a transactional database. Ironically FCP uses SQLite as a data store which supposedly has so-called "ACID" transactional integrity, which if used for preferences might give better reliability. However I think the standards and practices for Mac apps (inc'l API and framework support) emphasize use of .plist files.
Microsoft formerly used a similar approach with myriad Windows config and ".ini" text files, which then changed to a centralized registry database. The original concept was you never edit the registry directly, but apps will handle everything. However hacking the registry quickly became an ingrained practice. I think recent versions of Windows use write-ahead logging for registry changes so in theory it won't get structurally corrupt from partial transactions. OTOH it can easily get *logically* corrupt since the apps are responsible for managing their own data. Thus there are now myriad procedures and utilities to repair and clean up the registry, which was never the original vision.
I haven't used Windows in a while, but in my experience the centralized registry makes it difficult to do an "in place" re-installation of the OS, without losing all your apps. By contrast MacOS easily permits reinstallation and tends to preserve apps, since the app-specific data is stored in .plist files. Of course if those .plist files are damaged they will remain so after the reinstallation. So there are tradeoffs with each approach.
Much of this derives from the relatively primitive state of file systems on both Mac and Windows. Consider when you move a file then FCP or Lightroom doesn't know about it. People then say "only do that within the app", or "use this special procedure to tell the app it moved".
Ideally there would be a database file system which all apps would access via a standardized framework, then "moving" the file with Finder would automatically tell the app. In that scheme, app preferences would be stored in a secure transactional database integral to the file system and corruption would be infrequent. OS architects have long had the goal of a true database or object file system. It has been researched for decades, but the history of this on Windows shows some of the pitfalls. MacOS would have to navigate around these issues. Until then we'll probably be using .plist files: en.wikipedia.org/wiki/WinFS#Development
You are not only asking too much from Apple, you are asking too much from anyone who develops an operating system or any other kind of software.
So you're implying this is just how it is and we should just accept it and developers should not strive to be better because we live in an eternally flawed computer environment because developers haven't been able to move beyond .plist?
Reading the article you linked to, things are often written into the preferences file that are not associated with the application's preferences, such as last time the app was launched or likely in FCP's case, what Libraries are open, etc. Could this type of info not be written to its own .plist file to reduce the risk of corrupting user settings? That way if THAT file gets corrupted, it is easily replaced without redoing all of the settings and becomes far less annoying for the end user. I think that would work. Or Apple could also offer a way to retain the user-made settings when replacing the preference file. Literally nobody has thought of that before? I think you are being a bit too much of an apologist for Apple, but what else is new? They can literally do no wrong. The "Prefsetter" app linked to in the article now 404s.
@Redifer, that is a good question and I've asked it myself. Namely if .plist data problems are so common, why does that not happen in the library database? The FCP the library is very reliable, yet it's the same app.
MacOS supports "atomic" or unbroken writes all by itself. In fact when doing .plist I/O, the proper procedure is write the file using the method writeToFile:atomically:YES. That writes to a backup file which if successful is renamed the original file. It's supposed to handle cases where the app or system crashes during the write.
So what goes wrong? The speculation is the app just makes a mistake periodically and even though the write is atomic, the app buffer has the wrong data. In a heavily multithreaded app where many threads are synchronizing their work, it is easy to have a race condition, buffer overflow or "use memory after free" situation. In that case the thread doing plist I/O might write the wrong data.
But that same situation should also apply to library I/O, yet it rarely gets corrupted. As previously mentioned, the .plist reliability issue is not unique to FCP. That implies it could be inherent in how the .plist system is designed, which is essentially low-level I/O. Apps use functions likewritePropertyList, but I don't know how much validation that function does. The app itself must manually request an atomic write.
By contrast when an app calls a database to perform I/O on its behalf, the app layer interacts with the database on a higher conceptual layer. There is a lot more checking and validation, and transactional integrity can be implicit. The code managing the data is separate from the app and well debugged. If a mangled data buffer is submitted to the database, it will often catch that as a syntax error. That's just a guess.