WARNING: do not update to Scrivener 2 format after sync

I have now tested this with multiple scrivener files, unfortunately after losing substantial work.

Scivener 1.x file on computer A is saved and synced to server and computer B.
Scrivener 1.x file is updated to scrivener 2 format on computer B.

File LOSES BIG CHUNKS OF DATA, seemingly the last several days of edits.

Literally, I am looking at a scrivener file on one machine that, when I sync and update it on another is suddenly missing data, as though the clock has turned back.

I have cut and pasted below another user who has the same problem. This is NOT an issue of having the same document open on both machines or of not having synced the newest version. Updating a synced Scrivener 1.x document literally loses data.

It seems to me that safe dropbox/sugarsync integration should be top priority for future releases of scrivener. I get that you say no syncing is 100% safe, but I have been using various sync services for YEARS with Microsoft formats and have never had a problem like this. Warning people away from syncing is not a solution.

One step in the right direction would be to allow users to turn off autosave so that server-side versioning retains older copies.

Another step would be a big red-letter warning about sync incompatibility when the software is installed. I imagine a vast majority of writers use sync services. This is not a minor issue.

Re: Using Scrivener with Dropbox

Postby jimocarroll on Sat Dec 17, 2011 10:07 pm
I am grief-stricken. I have lost most of what I have written in Scrivener.

While it is possible to use Scrivener on files stored on Dropbox, do NOT use multiple computers to open Scrivener projects. I managed to corrupt my Scrivener projects by updating to the latest version on 2 laptops, and trying to reopen a project. First the program notified me that I would have to update the file and advised me that the saved file was possibly corrupt. Then it performed some kind of operation on the project files and informed me that the file could not be opened. One by one, I watched this happen to all my Scrivener projects. I have been careful to close all the projects before shutting down first Scrivener and then my computer. I have backed files up to scrivener zip files in another directory. Perhaps some of my writing is safe there.

Lesson? Install Scrivener on ONLY ONE MACHINE, and KEEP YOUR PROJECTS ON THAT MACHINE’S HARD DRIVE. You CANNOT replace writing that has been corrupted by trying to use Dropbox and multiple machines.

The format update process makes a backup copy of the project, precisely so that you can recover from an error during the update. Have you examined this copy?

What about the original copy of the file on Computer A? It should be completely untouched. (I’d suggest disconnecting that computer from the net when you look, though, to make sure sugarsync can’t mess with it.)

Remember that each Word document is a single file. Each Scrivener project contains potentially hundreds of files. A sync program that does not handle the links between files properly could do an enormous amount of damage. There have been a number of cases where sync programs “helpfully” synchronized “only the files that changed,” and inadvertently broke the metadata that allowed Scrivener to find those files.

One easy way to simplify recovery from this sort of problem is to have each copy of Scrivener store its backups locally, in a directory not accessible to the synchronization software. So:

Edit file X on Computer A. Save X to the cloud, X.Backup1 on A.
Edit file X on Computer B. Disaster occurs!! Cloud copy overwritten!!
Retrieve X.Backup1 from A, all is well.


Thanks for the help. I’ve now done what you suggest w/ regards to a local, non-synced backup copy. The more I investigate this problem the more it seems to be a syncing issue. But updating exacerbates the problem by rendering the file on the original computer non-openable in scriv 1.x.

The problem with looking at the original file is that once I updated it on computer B, sugarsync rewrote the version on computer A. The backup on computer B is a backup of the outdated file. All the versions on the sync server are useless because sugarsync autosaves so frequently; the server retains the five most recent versions which only takes me back a few minutes, not a few hours/days.

It’s disappointing that such a great program is so prone to failure with sync services. It’s true that Scriv contains hundreds of files. But I sync directories containing thousands of word and excel and pdf files, without a problem. I still think there needs to be a big prominent warning when you download and install the project regarding its poor compatibility with dropbox/sugarsync. I assume the developers will have to figure out some solutions if they still want the program to be used by the huge numbers of people who are moving their data and computing to the cloud.

The thread at the top of the page is devoted to using Scrivener with Dropbox, and I note that the second sentence in the first post has the words “we want to ensure users know that no syncing method is 100% safe”. That is why I (personally) would never use it. I use Dropbox quite happily by utilising Scrivener’s “Backup to” option, and saving a zip file of the project in the Dropbox folder. I like 100% safe, if I can get it!


I understand and sympathise with the problems that the original poster has been having. But I think that, probably in frustration, he’s made unwarranted extrapolations from his own experience about (a) the proportion of users who sync their projects between computers and (b) the riskiness of so doing, especially if, as advised, you keep separate, up-to-date local backups of your work, and sync with care. My experience, FWIW, is different.

In that case, the project was broken before Computer B ever saw it. That is, for whatever reason, the copy on Sugarsync’s server did not contain the changes made on Computer A.

See my response to your other post regarding the ways in which synchronization software can corrupt a project. It’s entirely possible that the new versions are there, but hidden where Scrivener can’t find them.

As I previously noted, the key difference between “directories full of Word files” and Scrivener projects is the metadata: files in Scrivener projects are not independent of each other, and so the synchronization software must preserve the relationships between them. There’s not much to be done about that from the Scrivener side, as the metadata is a critical part of what makes Scrivener such a powerful tool. Maybe your frustration should be directed at the Sugarsync folks instead?


Yes, you’re absolutely right. I think that scrivener saves so frequently that it may confuse sync servers. Multiple versions of the same file may be in the upload queue at once. I’ve modified the settings so that it saves every few minutes rather than every two seconds and I’ll see if this solves the problem.

Sure. And now that I’ve read that post, I’m figuring how to set things up to prevent future problems. But very few users will find that post until they’ve already encountered syncing problems. And honestly, that sentence should end “…safe to use with scrivener.” When sync servers detect conflicts they generate extra versions of files to prevent any data from being lost. This safety mechanism works extremely well for every common content-creation program (word, excel, photoshop, illustrator, acrobat, etc.), but it creates huge problems for Scrivener. Since Scrivener is the outlier, the software needs to warn users elsewhere than in a technical support forum.

I understand your point of view, but in fairness perhaps we should mention that the whole of Chapter 13 of the Scrivener user manual (Cloud Integration and Sharing) is devoted to the subject. The chapter is twenty-six pages long, which perhaps indicates that it is not a completely straightforward matter. There are also various other programs out there that use the package format for their “files” and need similar care when using cloud services. Old users of this forum have seen many debates about the problems and issues over the past couple of years or more, so I suppose by now we are well used to the idea that using the cloud is not always as straightforward as one might think. But commiserations – no-one likes to lose work.

Cheers, Martin.

Edit: in particular, section 13.6 of the user manual deals with potential problems caused by Scrivener’s use of packages.

Hi Martin

Yeah, you’re right, they do actually address this. I’ve been emailing w/ the scrivener folk and they gave some great advice on how to avoid these issues, which I’m going to follow.

That may be helpful if someone with a similar problem stumbles across this thread.

I also suggested to them that Scrivener look for evidence of sync conflicts before opening a project (for example, Sugarsync will rename a file “1.rtf (last modified by BJM)”. If a file like this is in the scrivener binder, the user could at least be warned. They seem interested in this idea, so maybe we’ll see it in a future update.

If nothing else, this has been a good lesson in not trusting my cloud syncing as my only backup and learning how scrivener handles files, at the expense of a couple of days’ work. Could have been worse.


In light of the OP’s experience, I wonder if perhaps Sugarsync is doing something particularly risky? I don’t know whether or how it works differently from Dropbox, but further investigation might be warranted.