Google Backup & Sync of local Scriv files?

I save my live projects locally on a drive connected to Google Backup & Sync. I’ve just discovered the warnings that live projects saved directly to Google Drive are subject to corruption and I’ve got all sorts of worries about whether my setup is risking the same.

I am wondering if Google cannot handle copies of Scrivener project files synced from local storage either, and stressing if Google backups of my work could be corrupted, or that there is the potential a syncing error could cause Google to overwrite my local project files with a corrupted cloud version any day. This would leave me with only copies of Scrivener’s zipped backups as my only recourse if my laptop falls into a woodchipper, still risking some loss of work.

If this is the case I’m looking at moving my project files out of the local drive syncing to Google, and crawling back to Dropbox just to store those files (while keeping Scrivener’s zipped backups saving to the Google-synced folder). I just want to be crystal clear that the upheaval is necessary.

Are you attempting to share the projects with any other device?

I’m not aware of any significant differences between Google Drive and Google Backup & Sync, and therefore would not recommend using either to share projects. There is less risk if you’re using Google for static off-site storage, but I still would encourage you to have some other backup mechanism as well.


Not sharing between any devices.
Just trying to weigh up if Google Backup & Sync of Scriv project files saved on a local drive carries the same risk of corruption as project files saved directly to Google Drive.
Am now looking into an external drive for backup storage as the safest bet, thanks.

What do you mean by “projects saved directly to Google Drive?”

Google Drive, Dropbox, and most similar services work by creating a local folder on your hard drive. Scrivener saves to that folder, just like it would to any other location on the hard drive.

Then the synchronization service uploads the files to the company’s server. If you’re synching with another device, there may also be changes on the server that it downloads, the ultimate goal being to make the local copy and the server copy identical.

To the best of my knowledge, Google Backup and Sync is essentially just a rebranding of Google Drive: the two work the same way under the covers. So yes, both carry the same risks of project corruption.

Note that these risks only apply to “.scriv” folders. The problem is that a Scrivener project can potentially contain hundreds of files, and it’s critically important that it have the same version of all those files. If you create a document at 9 AM, but the master index used to create the Binder was last updated at 8:50 AM, the new document will appear to be “missing.” Google Drive appears to handle Scrivener’s frequent saves badly, and can’t be trusted to upload changes in the order in which they were made, which is why it’s unsafe.

A ZIP file, in contrast, is a single file. It won’t change after it’s created, and it is uploaded or downloaded as a single chunk. Which is why ZIP backups are safe to use with services that can’t be trusted to handle .scriv folders correctly.


That’s exactly what I wanted to know - if the two services operate the same way under the hood despite the different product names. Will no longer keep .scriv folders anywhere Google touches for the reasons you explained, except for zipped backups. Thanks Katherine

May be Developers will just Fix Buggy Software ?
For IT competent people it’s obvious that this is not google problem …

For competent IT professionals who have examined the problem, it’s obvious that Google doesn’t provide a compatible solution for Scrivener. If Scrivener where to strip away a number of key features, and limit how large a project’s contents can grow, then maybe they could make it work.

Dropbox works. iCloud works. Box and Sync and other services work. Google doesn’t work.

Moreover, Scrivener simply saves projects to the disk. From Scrivener’s point of view, absolutely nothing is different between services that do work and services that don’t. Both are interacting with files on the disk, not with Scrivener itself.

So no, it is not obvious at all that this is a Scrivener problem.