Isn't it just a record of some parameters? If there's other stuff in it, why not put it in a separate file so that you don't lose your settings when you delete it? Why doesn't this happen in other apps?
iMac Line (2012 and Later)
betaneptune wrote:
Isn't it just a record of some parameters? If there's other stuff in it, why not put it in a separate file so that you don't lose your settings when you delete it? Why doesn't this happen in other apps?
It is a record of some parameters that have been set.
Preferences are loaded when the application starts. If this file is corrupted, wrong values can be read into the active parameters of the application. This can have devastating effects. If you have done even a small amount of programming it is easy to imagine how, for example, a loop with the wrong termination condition can step out of the bounds of an array - just to give a fairly trivial example.
What I meant was the closed state and other actions don't get written into the prefs file when the application crashes or force quits. For those things to be recorded the application has to quit from the menu or the keyboard and closed properly.
Not sure what you mean by write to a different file. A different file would have the same problem.
No, no, the preferences are user modified, but the preferences file holds a lot more, like the closing state. That's a user preference. Prefman is a good tool if you want to restore your preference set.
You mean exit handler that can operate while an application is crashing? I don't know anything about coding, so no idea if that's possible.
Tom Wolsky wrote:
What I meant was the closed state and other actions don't get written into the prefs file when the application crashes or force quits. For those things to be recorded the application has to quit from the menu or the keyboard and closed properly.
OK.
Not sure what you mean by write to a different file. A different file would have the same problem.
Write the preferences in the preferences file, and write all the other stuff that's currently written in that file to another file. this way you can delete that file and thereby not lose your preference customizations.
No, no, the preferences are user modified, but the preferences file holds a lot more, like the closing state. That's a user preference. Prefman is a good tool if you want to restore your preference set.
The closing state is a user pref? That's what should be written to a separate file.
You mean exit handler that can operate while an application is crashing? I don't know anything about coding, so no idea if that's possible.
Yeah, maybe the exit handler is only good when the app is hung. Also, a "nice crash" could dump memory contents, e.g., for analysis by the programmers, but maybe not with a "hard crash".
Just to add . . . corrupt preference files affect functionality in many other apps such as Adobe Premiere and Photoshop etc.
You might find this article of some use.
https://blog.frame.io/2016/09/13/recognize-fix-common-problems-fcpx/
I don’t know if there's a real reason it can’t be a separate file. You should use feedback to make that suggestion. There may not be any real reason other than that’s the way everybody does and that’s the way way we’ve always done it.
Ian R. Brown wrote:
It's not just FCP X and iMovie that suffer as I mentioned above.
I first came across the problem with Adobe Premiere around 2004 and then legacy Final Cut Pro/Final Cut Express in 2005.
If you do a Google search you will find that it is a common occurrence in most of Adobe's apps like Premiere, Photoshop, Illustrator etc. etc.
It appears that audio/visual applications are most susceptible.
Bummer. Thanks for the info.
Most commonly they are corrupted when the application crashes , which is when the closed state and other functions get written to it. That doesn't happen when there's a crash or force quit.
But why is this file being corrupted so often? And by what? FCP itself? How? No other files seem to get corrupted so often. I've written programs with parameter files and haven't had this problem. OK, not at the level of FCP, and it was in the 1980s, but still. If other files got corrupted this often, macOS would get totally messed up, and probably rapidly become unfixable.
It's not just FCP X and iMovie that suffer as I mentioned above.
I first came across the problem with Adobe Premiere around 2004 and then legacy Final Cut Pro/Final Cut Express in 2005.
If you do a Google search you will find that it is a common occurrence in most of Adobe's apps like Premiere, Photoshop, Illustrator etc. etc.
It appears that audio/visual applications are most susceptible.
You say it happens when the app crashes, but then you say it doesn't happen when there's a crash. Please clarify.
So then why doesn't it write those functions and stuff to a different file?
The preferences, AFAIK, aren't modified except by the user, and I have yet to see the program crash while changing the preferences.
Why isn't there an exit handler that can handle this? OK, that might be tough to do. I've written exit handlers in DCL command procedures (scripts), but I don't think I've ever done it in compiled code, and it was years since I've done such stuff.
Actually, I recall now that there are exit handlers in compiled code. The Unix/Linux kill command has the -9 option, which is a sure kill, as it doesn't allow the exit handlers to run. At one place where I was an OpenVMS system admin, the previous admins wrote a FORCEX command, which would be gentler than the STOP/ID=nnnnnnnn, which was the equivalent of the kill -9 command, AFAICT. But there may well be something else involved. I don't really know. Oh, so I'm guessing that a Force Quit in macOS is the equivalent of a kill -9. Is that right?
I can't explain the technical reasons as to why it does it.
Suffice it to say that it does damage functionality.
This is a free app which can save your preferences whilst they are good and replace corrupted preferences with the good copy.
https://www.digitalrebellion.com/prefman/
It saves you having to reset any special preferences you have made.
betaneptune wrote:
But why is this file being corrupted so often? And by what? FCP itself? How?
That is a good point.
It does seem that the preferences for FCP tend to be corrupted far more often than one would expect.
So how does a file that stores preferences get corrupted in the first place? Seems to me that it should only be modified when the user does so, unless there's other stuff in there, in which case why not put that other stuff in another file so that you don't wipe out your personalized preferences?
Yes, I did some programming years ago. Yes, I can see problems from messed up data in the preferences file, but I still don't see how it gets corrupted in the first place. Aren't there plenty of other files that if they get corrupted would cause big problems? OK, I guess that's where the totally reinstall from scratch bit comes in.
Hard drives have special firmware or whatever that in the event of an app or OS crash, or a sudden loss of power has firmware that keeps critical file system files from getting corrupted to the point where you can't even mount the drive and access files, at least. Why can't something like that be done here?
Why does a "corrupted" preferences file break stuff?
