Bigger Scrivener files (say 400 Mb) that are backupped automatically by Scrivener with the built in zipper, can take quite some time to zip (over 10 sec.). Why? Because they are not only zipped, but also compressed.
When one regularly opens and closes these files through the day the waiting can become quite annoying. Also because one cannot work in another Scrivener file and the spinning zip wheel stays on top of all windows.
When zipping without compression, zipping goes blazingly fast, also with big files (1-2 sec.). Even a 1.5 Gb Scrivener file takes no more than 5 sec. I tested this with Keka (Keka - the macOS file archiver).
Surprisingly, on my Macbook Pro 15" mid 2015, 2.8 GHz i7 (DG) 16GB/1TB, the Scrivener zipping process takes about the same time as on the M1 iMac 24" 16GB/512GB of my girlfriend. So buying a new AS-processor Mac wouldn’t change something substantially in this respect I guess.
So, my request: Set uncompressed backup zips as default.
Furthermore, when automatic backups are set in the prefs, the minimum is three backups. Why? To be save with different versions most likely. But we also have Time Machine, and most cloud services make backups of older versions.
So why not let users opt for just one backup per file? That is also the most space friendly option for where space counts the most: on the internal disk.
So, my request: Allow for just one automated backup (not three as minimum).
I don’t know for sure (I’m neither part of the design team, nor an LL employee), but my guess is it’s to prevent against the error you don’t notice immediately because it’s not in the part of the manuscript you’re currently working on. One backup means if you don’t notice straight away, you’re in trouble.
Of course, three backups means if you don’t notice in three goes, you’re in trouble so it’s all a question of comfort and degrees of risk. The line has to be drawn somewhere, and my guess is that drawing it here means almost all support requests for these sorts of problems can be resolved by reverting to a backup… and at only one backup that wouldn’t be the case.
Many archive programmes let you change the compression ratio for archive files, including ZIP format. I believe when the archiving app offers you “no compression” it’s technically compressing with a compression ratio of zero.
My guess is (see previous caveats), is that while you’re an informed individual with sensible alternative backup solutions in place, there is no way of checking that everyone that turns that down to “1” is as on the ball as you… and so they are keeping support requests manageable and making sure the programme does everything it can to prevent data loss.
I for one find that approach very confidence inspiring.
Why are you doing that? There is no necessity I can think of for a Scrivener user to mess with the backups until there is a need to restore a project. For myself I have only once needed to restore a backup and use Scrivener on my Mac mini, MacBookPro, iPad, and iPhone.
I too work on one project then another and a third etc throughout the day anything up to to seven or eight or more but I do that in Scrivener windows that are kept open then switch between them either from the Window menu or the shortcut to go to the next window (for me as a macOS user that is ⌘-backtick or ⌘-shift-backtick) and as I do with Firefox where I have 18 browser windows open at the sametime. I have auto-save set (using the default value). Also my projects are all stored on Dropbox so they are secured against machine failure.
I see no need to be constantly opening and closing Scrivener projects throughout the day.
Or, while I don’t recommend this, turn off automatic backups and initiate them manually. In your work process, will save a lot of time. Or, tweak the backup options to suit your tolerance for time. For example, only on close, not both open and close, or something like that. Up to you.