I was curious about how to change the default options for new projects? I often “save as…” a new version (BookNameV1, BookNameV2, and so on) of a book before I dive into a major revision. I am able to save and load options under options->general->manage, but it would be nice to not have to remember to load them every time. It’s especially important because the automatic backup location seems to need to be set with every new save as of a project. I’m talking about options such as “take snapshots of changed text documents on manual save.” Is there a way to have “Save as…” keep all the same options without having to load them from a .prefs file or do any of them manually? Is there a way to have all new projects start with my desired .prefs file loaded as the default options?
Backup options can be set globally, for all your Scrivener projects, via File > Options > Backup. New projects are supposed to adopt these global defaults.
Backup options can also be set for specific individual projects, via Project > Project Settings > Backup.
Generally, people use global settings for most of their projects, and individual settings on an exception basis.
A possibility is that you’ve used the individual project backup settings for this particular project, and when you do Save As, the new project is defaulting to the global backup settings. You can correct this by going to Project > Project Settings > Backup and disabling Use custom backup folder for this project.
But if you’re not using individual backup settings for your project, then this is either a bug or there’s something you’ve left out about your process. (I’m thinking bug because I would assume the Save As operation should result in a project identical in every way to the source project.)
A way to completely avoid all of this is to avoid using Save As to create new versions.
Instead, when you want to version your project, use File > Back Up > Back Up To to create an appropriately named zipped version of your project in a Versions folder. (Don’t put this zipped version in your normal backup folder with your regular backups, keep it in a separate folder so Scrivener doesn’t delete it when you hit your File > Options > Backup > Retain backup files limit.)
There are a few advantages of this method, in order of relative importance:
As you will need to unzip a version to open it, it’s far more difficult to accidently open and modify an older project version.
Because your main project never changes, you’ll never encounter the sort of issues you’ve detailed in your OP.
The zipped versions are in a separate folder from your live project, avoiding clutter.
Your zipped versions will take up less space.
As to disadvantages of this approach, if you frequently open and refer to your older versions, #1 above would probably be considered a major negative.
I’ve been fortunate enough to not run into any major trouble so far, but I think I’ve had a few near-misses this way. Grateful for the advice and to not have to learn it the hard way!
That’s mainly because the recovered file will have the identical name as the main “current” version. This makes handling backups way more risky and error prone than need be. This could be prevented with a simple fix:
When Scrivener creates the timestamped zip file with the name “ProjectName-bak-2022-02-26T16-18.zip,” it should also rename the internal project folder and scrivx files with the same timestamp, locking container and contents together as a unique backup set. That would make it impossible for a bak to overwrite a current.
The FIRST thing I do when I unzip a backup is copy the filename from the zip file to the project folder and scrivx file. That shouldn’t be necessary. Scrivener should do that at the point of origin. This would be a super simple thing to implement (Qt willing, I suppose) and would save a lot of trouble and panic and heartache.
I believe what @kewms means is that using the “Save As” method is a common cause of “lost” work in the support queue. This is because “Save As” results in two live projects. Also, the Recents list points to the prior version. These factors make it too easy for user to inadvertently open the wrong project and make changes, and subsequently open the right project and freak when their their changes are “lost”.
But I completely agree with everything else you wrote. Renaming the backed up project folder inside the zip file would be a marvelous change.
Actually, “Save As” creates a copy, and then continues working in the copy. So if the user thought they were “just making a backup,” they’ll be surprised to learn that the work they did after the Save As command is not present in the “original.”
Because a “Save As” copy is not a “backup,” it will have whatever name the user chooses to give it.