RedTruck wrote:
Whenever you have a program that has an autosave, as well as an unlimited amount of undos, the computer has to keep every version of the file open to that you can return to it when you hit cmd-z.
<snip>
Anyway, the point is, you can't have any more than 256 files in your undo stack. Either find where the stack is stored, or quit and restart regularly.
I know you mean well, but this is misinformation.
Apple is using a database called SQLite, which is the file format of the Event and Project files. See: http://www.sqlite.org/about.html for an overview about this database format, but it essentially allows Apple to implement autosave using the built-in transaction-level safety features of SQLite. That means each "change" to the file is guaranteed to either happen or not happen; you can't end up in a half-way corrupted state, as you might if you were using those aforementioned regular files by keeping them "open" all the time.
When a change occurs in FCPX, the file is opened, the database is updated atomically, then the file is closed. You can actually see the project file get incrementally bigger after each edit action you take. If a problem occurs (such as a crash) at any time, SQLite technology (theoretically) guarantees your file will simply be the same as it was before you attempted the change.
Now, when the "undo" feature stops working, that really is telling you that autosave stopped working. There's a good chance that there's a "silent" problem (bug) that is not allowing the changes ("autosaves") to be written to the database (project file). Nothing is getting successfully written to the single file that represents the project. Since nothing got written, there is nothing to "undo." Thus, "undo" becomes unavailable.
Whether this is a bug in Apple's FCPX code (most likely), the OS (less likely), or SQLIte (least likely) has yet to be seen. But there's a bug somewhere, that's for sure. Why this is happening to just some people is still a mystery. Hopefully Apple can figure it out soon.
As for where the "undo" information is being stored, since you can't "undo" changes after you close the application, this highly suggests that Apple implements "undo" in the application's memory space (and not using extra files in a hidden location). Basically, inside memory, Apple stores the information needed to "roll back" updates it did to make the database changes in the first place. As someone else mentioned, this would be some sort of "stack" structure.
The undos can be "unlimited" because a 64-bit application can address a HUGE amount of memory (theoretically 16 exabytes). The operating system takes care of letting the application do this behind the scenes using temporary files (called swap space) if the application needs more memory than is actually available. This causes slowdowns, but it doesn't prevent the application to use more memory than what you have physically installed (4GB for example). So, the fact that FCPX is 64 bit and FCP7 is 32 bit is the most probable explanation as to why the undo limit changed from 99 to unlimited. 32 bit apps have a theoretical 4GB limit, which would certainly make unlimited undo impossible for a program as complicated as FCP.
What can you do with this information? Not much, I suppose. But you shouldn't expect any security based on quitting more or less often; the only real way to know that undo stopped working it to continually check if it is still available to use.
