Dropbox and syncing


When I’m writing in a Scrivener UK stage play project it doesn’t seem to sync with that project in IOS Scrivener.
I’m having to remove it from the dropbox file then put the same project that I’ve been writing in into the Dropbox file.
But then I haven’t got the project to continue writing in. Or am I supposed to open this project from Dropbox when I want to write in it and then make sure it returns to the Dropbox folder when I’ve finished writing?

I know I’m doing/not doing something that a small child could do but there aren’t any small children available.

Any suggestions much appreciated.

There’s a guide to synchronization here: scrivener.tenderapp.com/help/kb … g-with-ios

You shouldn’t need (and don’t want) to move the project in and out of Dropbox. Just install the Dropbox software, which will give you a “Dropbox” location in Finder. Put the project there and work on it just as you normally would.


Got it, thanks. I was making things more complicated for myself than I needed to.

Dropbox syncing was never a problem for me when using my iMac and and iPad Pro, but having bought a new MacBook Pro (2019, it arrived today) it seems I now must make sure to quit Scrivener on one device (or at least close the document) before attempting to work on it on the other device. Is this correct? I know I can have the application automatically quit after a certain time, but that seems sub-optimal (because I’d have to relaunch it when returning to the device). And I’m puzzled by the need to close a document on one machine before opening it on another. Scrivener saves to Dropbox automatically every few seconds, so what could go wrong?

But it’s likely that I’m overlooking something here, in which case: please enlighten me!

What could go right?

It’s a recipe for work being overwritten and lost.

Perhaps I failed to properly explain myself. If I have a document open on device 1, and it auto-saves every 2 seconds, even if the saving takes, say, another 4 seconds, I’d have to try really hard to mess things up. I’d have to run to device 2 and start typing, all within a few seconds.

What I really want to know is: is quitting or auto-quitting the only way to avoid the (superfluous, to my mind) warning dialog?

Quitting and not waiting for an auto quit is the only way to ensure no conflict and potential overwrite.

Scrivener saves to the local disk when you are idle for the specified number of seconds.

Scrivener doesn’t save if you aren’t idle. So if you type for an hour straight without lifting your hands from the keyboard, none of that text will be saved until a save event – idle time, shutting down Scrivener, a manual save – occurs.

Scrivener has no control over the upload from the local disk to the Dropbox server. If your internet connection is misbehaving, if you’ve reduced the priority of Dropbox connections for performance reasons, or if Dropbox is accidentally or deliberately paused, the local changes may not be reflected on the Dropbox server.

Moreover, the changes then have to download from the Dropbox server to the second device, and are subject to the same delays there.

From empirical observation, there also appear to be processing delays on the Dropbox side. That is, finite time passes between when a file is uploaded and when it is available for download to other devices.

If you are seeing the warning dialog, Scrivener believes the project is open on another device. Attempting to edit a project on Device B when it is open on Device A is unsupported and entirely at your own risk. So no, the warning dialog is not superfluous, and should not be ignored.


Here’s what:

You make changes to a project on device A, leave it open, and then edit the project on Device B,

You type 1000 words on device B.

On device A, the project is still open. Scrivener does not explicitly load mobile changes unless you tell it to (File → Sync → With Mobile Devices), and you forget to do that. So, when you look at the project, the 1000 words from device B aren’t there. You panic. You type a quick outline to remind you what the missing thousand words said. You close Scrivener.

Blammo the version of the project on device A is now newer than the version on device B or in Dropbox. So the device A version overwrites the others, and that 1000 words is now gone forever.

That’s what can go wrong.


Alright, that’s scary! I guess I’ll have to try and make quitting Scrivener when I’m done, on every device, a habit then. This doesn’t fully get rid if the risks, I think, because if the internet connection malfunctions or Dropbox is slow, like you offered, things might still go wrong. But then at least one would have the local copy, perhaps un-uploaded, in the device’s Dropbox folder. I do wish things were a little easier, i.e. mindlessly automatic, but that’s probably very difficult to achieve. Thanks for your comments.

This is why we recommend storing Scrivener’s automatic backups either on the local disk or with a different cloud service. So they’ll still be there regardless of what Dropbox tragedies might occur.


Ah, but they are! And that’s essentially what’s creating the problem.

First, the thing that makes Scrivener projects so special, that makes it possible to have loads of research material and several hundred of thousands of words in the manuscript and not make the computer slow down, is that every sub-document you have in the binder is stored as its own file on the hard drive. A Scrivener project isn’t a file, although it looks like that on a Mac. It’s a folder with perhaps thousands of files inside it.

When you are working on a project, Scrivener only opens the files you have visible in the Editor. One advantage of this is that if something happens to your computer while you are writing, only the document/file you have open in the Editor is affected. This makes Scrivener’s file system very robust.

Secondly, when you have your projects saved on Dropbox, they are not. They are saved on your Mac, in a folder called Dropbox. The only special thing with this folder is that the Dropbox app you have running on your Mac is always watching that folder and uploading any changed files to the Dropbox server, and also watching the Dropbox server to see if any files over there has changed and if so download them to the Dropbox folder on your Mac.

If you have the project open on two Macs at the same time, you could easily end up in a situation where both Macs try to read and write the same document (file) in your project. The Dropbox app on either Mac doesn’t know this. It only compares the files in its own Dropbox folder on its own Mac with the files on the Dropbox server. If it thinks that the version on the Dropbox server is newer, it will download it to its Mac and overwrite the document/file you have there.

In the worst scenario, what you are writing in a specific document on your Mac would suddenly disappear, because something happened on the other Mac, telling the Dropbox server that its version of the document is the newest, and the Dropbox app on your Mac simply getting that info and thus downloading that version from the Dropbox server.

Everything IS automatic, but computers aren’t very intelligent, so if three computers are simultaneously accessing your project (your two Macs and the Dropbox server), there will be trouble sooner or later.

Always close the project when you are not working on it, and always wait for the Dropbox app to upload any changes before closing the Mac.

I didn’t want to start a new thread for this, and it’s related, so I’ll put it here. While I accept that one needs to take all the precautions described above to prevent loss of content, I must admit I was a bit disappointed when I found that quitting Scrivener didn’t save the full state of the application. I had a text I was working on in the left editor, a PDF in the second editor, and a second PDF in a copyholder attached to the second editor. I was hoping (and, given the overall level of sophistication of this wonderful piece of software, more or less expecting, too) that relaunching Scrivener (on the same device) would restore these three panes, and even (optimist that I am) restore their respective scroll positions. Instead, the two editors opened, but the copyholder didn’t, and the PDF in the second editor showed its first page. I have no idea if this is very difficult to implement or not, but to have the full state of the application, including scroll positions, restored would certainly be a boon.

No, it’s not related so you’re more likely to get a response if you start a new thread with an informative title.