This wasn’t a Scrivener crash, but the consequences of my Mac crashing for unknown other reasons while Scrivener happened to be opened in the background:
Project had been saved under a new name via “Save as…”
Mac crashed for entirely other reason (rare kernel panic). After restarting, Scrivener re-opened the original file, rather than the file created by “Save as…”.
Much confusion as subsequent editing was performed on wrong draft (resolved with some side-by-side editing).
I wouldn’t say this is “expected” behavior, but it isn’t surprising.
One of the things that Scrivener saves during a normal shutdown is the interface state: what projects are open, and with what layouts and open documents.
The crash would have prevented a new “state” file from being saved, causing Scrivener to revert to the previous one.
For future reference, I generally recommend File → Backup → Backup To, rather than Save As. Many people find the Save As behavior confusing. In any case, when you have multiple versions of a project be sure to use a naming convention that makes it very clear which version is which.
That makes sense, even if arguably poor UX. More kicking myself for not noticing until I printed a scene for editing on paper. Only then did I see the document header had the wrong version.
Feature request: Write the open document to the config file on “Save as…”, not just when Scrivener is shut down
EDIT: As for naming conventions, I do version my documents. But I missed this being the “[project name] spring edit” rather than “[project name] summer edit”.
Feature request: Write the open document to the config file on “Save as…”, not just when Scrivener is shut down
Here is Apple’s feedback form. The “recent” menus throughout the entire system, including from the menu itself and in all native software’s File menus, are run through a central infrastructure for this sort of thing. In this one facet we might say it makes sense to go against the convention of writing configuration on shut-down, and instead doing it whenever, but there are good reasons for that policy in general. If preference files are updated immediately, then setting preferences that cause a crash can result in systems the don’t boot or log in, or software that can’t launch, without much more difficult troubleshooting measures.
As for recovering from a mistake of editing a prior version, there is a tool you can sometimes use to help with that. Check out §5.3.2, in the user manual PDF, starting with subheading, Merging Changes from One Project into Another. While normally you would use this to collaborate with others, it’s also a very effective “oops” correction tool.
Hah, the software engineering equivalent of writing yourself into a corner—one edge case UX problem caused by trying to avoid another problem. Their response makes sense, even if it is bad UX.
For Scrivener specifically I wonder if the concept of “versioning” a document would work? Then after starting a prompt for “a newer version of this document exists…”
It was unfortunately misunderstood as being an alternative to Dropbox, and taken off the list of things to complete. It’s on a high priority list now though.
