dropbox conflict resolution

Hello again,

when synchronizing my Scrivener project with Dropbox I end up having conflicts. The only conflict I had up to now is the conflict on binder.autosave file. If I the word ‘binder’ is not misleading, that is the tree of files.

While losing rearrangements or some icons is not so much of a problem on the occasional conflict, losing new texts is. So:

  1. Is there a way to merge binders; or:
  2. Is there a way to scan a project for rtf files unreferenced by the binder?

Or some other way to make sure no texts are lost?

If there are rtf (and synopsis, document notes, etc) in the project that are not referenced by the binder, creating “new” documents should cause Scrivener to discover them. Essentially, creating a new document will create a new binder entry with whatever binder name you give it, which will internally refer to, for instance, “297.rtf” in the internal project package. If there’s already a 297.rtf file, then Scrivener will simply load that file as its contents using whatever binder title you gave it.

Does that make sense?

It does make sense, thanks. Yet, this workaround only works if the existing unreferenced files have ids that happen to match a new id that is just being incremented. A slightly older file would then not be detected.

There’s a detailed procedure for resolving Dropbox conflicts here:

The best cure is prevention, though. There’s a discussion of best practices for avoiding Dropbox conflicts here:
scrivener.tenderapp.com/help/kb/ … th-dropbox


The thing is, automatically finding unreferenced files, be it from Dropbox or from another sync service, is not difficult to do, and can be done automatically with a little amount of code. I think this should be a feature of Scrivener. The conflicted or unreferenced files could be imported automatically under an Unreferenced folder created on the spot. People would see there their conflicted stuff without having to make their way among hundreds of numbered rtf files.

It’s not hard to do, it makes a lot of sense, and it would be pretty useful. Everybody* uses one cloud or another today.

  • almost

Out of curiosity, do you write code for a living?

The above is from a legal statement made by a person whose job it is to keep a major cloud service running. I expect it will see the light of day before too long, but the position of this particular company is that team like L&L have no obligation to support a cloud for formats that are not approved for cloud use.

That should be a little worrisome for folks.

I do.

But I’m afraid that cloud danger warning is a bit overkill. People have been using sync systems like cvs, git and now the more democratic dropbox clones for some time. Not only you get to sync your stuff but you backup it at least on the server (and on the other terminals). It seems pretty obvious.

And, the scrivener format is just about perfect for dropbox sync as it is really a folder with small files. The only risk of unresolvable conflict is on the central binder which, for small changes, I don’t even really care about. The small rtf-files are easily atomically sync-able. So even on conflicts, as far as I’m concerned, the only real risk is that of losing new content.

Good luck explaining that to a writer who just lost a day’s work. Or more.

I use cloud services for my own work. I find them very useful. But I also keep multiple non-cloud backups, and encourage anyone who is serious about their data to do the same. If a single point of failure can cost you more data than you are willing to lose, then your system is fatally flawed.


Actually, my meaning was somewhat different. If you have a conflict of an rtf file, what dropbox will do, will get you a new ‘conflicted’ file which is ‘new content’ unreferenced by the binder and which should be rendered visible in the project.

Of course losing a day’s work on rewriting or editing text is to be avoided. But as rtf files are small, chances on having conflicts on them are smaller than on the unique binder. So what I meant is that conflicts on content, on the rtf files, are the important thing and that new content or – I should add explicitly – conflicted content, which is also ‘new’ content, that is, new and unreferenced rtf files, should be rendered visible in the project.

I also said that rearrangements in the binder — given that they are only rearrangements, that conflicts are by nature occasional, and that to my knowledge diff-ing trees is not simple work — is not as important, I can live with occasionally losing this rearrangement. But that as, in opposition, adding unreferenced files is reaaaally easy to do, is also a way of keeping the project coherent as unreferenced fils should not be there in the first place, I think that this should be a feature of scrivener — even if dropbox did not exist.

That was my meaning.

There are a couple of details to remember here.

First, a “conflicted” file, whether the binder file or an individual RTF file is not necessarily (or even normally) “new” or “unreferenced” content. It is a file in which Dropbox is unable to reconcile the version in the cloud with the version on a local system. If, for instance, you edit the project on Computer A, it fails to synchronize correctly, and then you edit the same file on Computer B, then there will be two versions of the edited file, Dropbox will be unable to resolve the conflict, and so it will assign one of them a name like “conflicted copy of…” So while the file itself may be new, (most of) the content in all probability is not.

By definition, it is not possible to resolve this conflict automatically. If it were, Dropbox would have already done so. Moreover, Computer A and Computer B won’t necessarily (or even typically) have the same conflicted files. Thus, there is no guarantee that simply renaming the file and slotting it back into the Binder will resolve the conflict. Certainly doing so without clearly explaining to the user what has happened is a recipe for disaster. Human intervention is always going to be necessary to decide which version is definitive, or possibly even that both versions have elements that should be kept.

Second, maybe your RTF files are small, but there is certainly no technical requirement that they have to be. Plenty of people stick entire chapters with thousands of words into a single RTF file. And since the RTF files are where the actual writing happens, it is entirely plausible for a single editing session to touch many different RTF files, all of which can then potentially produce conflicted copies if a synchronization error occurs.

Similarly, maybe your Binder rearrangements are “occasional” and “unimportant,” but that certainly is not the case for all or even most users. Indeed, the ability to quickly and easily reorganize one’s outline is a major selling point of Scrivener, and so it would be surprising if our users as a group didn’t make extensive use of this feature.

I actually agree that it might be helpful for Scrivener to be able to detect the creation of “new” files within the project. (Although I am not a developer and therefore have no idea how difficult this would be.) But I think the disposition of those files is always going to require a fair amount of human intelligence well beyond “rename the file and add it to the binder.”