I do agree with the above, that both of these concerns are best handled as an aspect of general-purpose file management.
Typical case would be when looking back at an old project - I want to read it but not update it; the automatic save changes the ‘last modified’ date it gets in the finder, messing up my ability to search or scan old scrivener projects by date.
I don’t place much trust in file system modification dates for this and many other reasons. It’s hard to beat a date stamp that is encoded as part of the file name itself. That aside, I can at least share what I do for old projects: once a project is to the point where I am no longer work on it, I file it to an archival folder, where all old files go to rest, and I tend to compress to zip the files I’m no longer working on.
There is an important side-effect in doing so (outside of simply saving space and reducing the indexing overhead of archives to one file per major project), and that is if I want to in the future consult information from these old files, double-clicking on the .zip produces a brand new copy
of the folder/project every time, and every time it is identical from the original. I open the project, get what I need out of it, and when I’m done I trash it, leaving the .zip copy for long-term safekeeping.
It is the closest thing to a pure read-only long term archival system that you can achieve on most modern file systems. Almost everything otherwise, such as permissions and file system locks, tend to either not work well across all software, or can be trivially overridden. I’d rather old stuff be very difficult to modify without a process that involves many steps that must be intentionally taken. Actually overwriting and updating the contents of a .zip file fits that description perfectly.
The same goes for backup. I’ve done my best to disable all automatic backups because if you’re not careful the last 5 backups are near identical - where what I want is backups that preserve major revisions (in concert with snapshots of course).
Out of curiosity, if you are taking care to create your own backups manually (and Scrivener provides several convenient ways to do so), then why turn off the automatic backup? At worst, it’s not always useful for the reasons you specified (though as noted you can adjust the settings to avoid problems like that!), but I would be willing to wager that more often than not there is at least no harm
in having five near-identical copies.
Oh and here is a hint for archival projects: if a project is well and truly to that point where, even if you don’t use my method as described above, you are done editing it and don’t want backups made of it in the future, then go into Project ▸ Project Settings...
under “Backup”, and exclude the project from backups. Now you don’t have to worry about losing the older copies to subsequent review sessions in the future—of course if you date stamp your old projects in the file name, you also conveniently duck that problem entirely.
I use a combination of manual and automatic backups for these and many other reasons. Here’s what I do:
- For major “save points”, which can happen once or twice per day in an actively edited project: File ▸ Back Up ▸ Back Up To.... This file will be date and time stamped and can be optionally zip compressed (again see above for why that is a good idea for projects you don’t want to accidentally edit). These get saved into a separate folder that I use for these kinds of backups (only the most heavily worked upon projects get their own subfolder). I’ll sometimes name the backup according to what is going on as well. Perhaps I’m overhauling keyword organisation, I’ll call the backup “Pre-Keyword_Overhaul” along with the project name and date stamp. I’ll always have a copy of the project in that state, years from now, in case I ever need the old organisational schema.
- Automatic backups: though I set my to save 25.
On top of these, any protections I add myself (such as the background SpiderOak process that encrypts and stores all important data to another geographic location, or even Time Machine) are keeping track of these backups on top of my own organisation of them, and Scriveners automation. I.e. if Scrivener deletes the 5th oldest backup before you wanted it, that may not actually be a problem for you if every few minutes these things get uploaded or saved to a drive.