Hi! I’ve been really enjoying Scrivener. I’m keeping my writing in sync across multiple devices using the alternate method described here, but there’s a small convenience feature that would really help.
If you follow the guide and set the Backup location on all your devices to a shared location (e.g. cloud storage folder), you might end up with a backup file that is newer than your local copy.
So I propose that, if Scrivener finds a newer version of your current .scriv project in the Backup folder, it should pop up a window asking you what to do. Your options could be:
Replace the older file with the newer backup.
Scrivener copies and unzips the backup automatically, leaving the original .zip in place.
There could be a toggle for whether the older file itself is backed up before replacing it, or simply deleted.
Unzip the newer backup and save it elsewhere. (A file dialog will pop up.)
Ignore the newer backup for now and open the older file.
Currently, you have to manually copy and unzip your backups, which had me thinking, “Can’t Scrivener just do that?” It would make the alternate syncing method just as convenient as keeping the .scriv folder in cloud sync – and MUCH safer.
(I used to keep my project file in a Syncthing folder, but a corrupted project convinced me to go back to the alternate method.)
Thanks for reading!
It can.
You are using the wrong method imo.
Technically, a backup is for backup.
What you need synced and made available offline across your devices is the project itself ; not zipped or anything. This way there is only one version of it, and so it is inevitably ALWAYS the right / most recent one. (And you don’t have to manipulate/unzip files. You have nothing to do other than wait somewhat and make sure your cloud is done syncing when accessing the project from a device other than the one you last used.)
Safer how ?
As long as you properly backup your projects, the current system is in no way unsafe or not as safe as not syncing and only using one computer. (Aside from the cloud providers’ nasty habits themselves. – Which sometimes causes annoyance and confusion, but rarely (if ever) destruction.)
As a matter of fact, the way to go about it you described IS unsafe. It is only a matter of time before you invest hours of your energy and enthusiasm editing the wrong version of your project. – Spare yourself the disappointment.
Absolutely not. Scrivener should never delete a project. This is just asking for trouble (and angry support emails).
Yes, you will. In fact, that is the entire point of this method. That’s why a key step in the article you cite is:
Enable the setting to use dates in backup file names. This will make it much clearer which backup is the most recent, which you will be doing a lot of with this method!
Edit to add: And note that if you follow that procedure, the old and new versions will have different names, and therefore from Scrivener’s point of view will not be recognized as the “same” project.
If our alternative method is followed as described – which I’m not sure the OP is doing – it’s at least as safe as syncing live projects.
The difference is where the risk comes from.
I can say that inappropriate cloud syncing settings are by far the most common cause of “lost” work these days, and there isn’t a close second. That’s a major risk: you and I know how to handle the “annoyance and confusion,” but many people don’t.
With the alternative method, it’s always completely clear which version is "current. The “risk” is that the user has to pay attention and check. However, even if they don’t it’s a relatively simple matter to merge two closely related projects. The alternative method ensures that both versions still exist, rather than the “wrong” version having been overwritten by an automated process.
Well, I agree, and I don’t at the same time.
If syncing between computers is incomplete, a second to last zipped-backup version will appear as being the most recent one even though it is not – the timestamp being of no help, since the most recent file isn’t actually there to state that IT is the most recent one. But other than that, if done properly (meaning: the user gave the sync the time required) there shouldn’t be a problem, indeed.
Still, as a user, I wouldn’t feel comfortable with this approach. – Using zipped backups for sync, that is. (Too close to the potential problems of abusing save as to my taste.) But that’s just my opinion.
Fundamentally what happens is that the cloud service “helpfully” decides that “old files” can be stored exclusively in the cloud to “save space” locally. Since a Scrivener project can contain many different files of varying ages, this means that parts of the project can “disappear” because they aren’t available locally when Scrivener wants them.
How likely this is to occur depends on the algorithmic choices of the particular cloud service and the speed of the internet connection. It’s more likely to happen with less frequently accessed projects, but even brand new projects aren’t immune. Note also that some services – looking at you, Dropbox! – store files exclusively on their servers by default.
Across both platforms and all cloud services, the solution is to configure the service to “keep downloaded” or “make available offline” or whatever the specific service calls it.
OneDrive as well. At least that was my recent experience after a fresh install of Windows 11.
Theoretically at least, L&L could code around this with error handling, by having Scriv wait a bit then try again if a doc isn’t retrieved on first try. (The syncing service is supposed to retrieve the file when it’s requested.) But the really insidious side effect of the Files on Demand storage setting is the high probability that Scriv’s zipped backups will always be incomplete. Even if L&L managed to code around the doc not found issue, so that Scriv could work better with Files On Demand, there’s nothing to be done about the backups.
Google drive is terrible for this.
(I am so glad I never had the bad idea to sync anything Scrivener-wise with it.)
I doesn’t actually keep files in the cloud, but it so damn often, which is almost the same, waits for the user to refresh the folder (there is a secret/hidden menu for that, – one needs to know the key+mouse combination ; shift + right click) without any clues as to the fact that stuff in the said folder isn’t actually synced at all.
