Potential Synching Issue between Windows and iOS

Hi there,

It finally resolved itself today, but this behavior happened four times yesterday.

I had created a new doc for a new scene at the end of a chapter (folder) in the iOS version, did some writing, closed the project, synced with Dropbox. Opened in Windows, did some more writing, and also decided to move the scene to the beginning of the chapter (folder). Saved, synced with Dropbox.

Synced iOS and Dropbox and opened project. All the text changes I made in Windows had accurately saved and synced, but the document was moved back to the end of the chapter (final doc in the folder). Typed some more, saved/synced, closed.

Opened the project back in Windows, and because I had now saved and synced in iOS, the doc was also at the end again in Windows. Moved the doc back to the front. Also swapped the location of two chapters (folders). Saved and synced.

Synced on iOS again, and, again, the text changes were kept, but it once again moved the doc to the end and also the folders were in their original positions instead of being swapped as they were supposed to be.

This kept happening repeatedly all day yesterday. All the content changes were syncing, but on iOS for whatever reason binder organization was not syncing correctly.

What seemed to work was today after I made changes in Windows, I wanted much longer to open and sync in iOS. I don’t know if it was just a weird hiccup and there is no bug, or if there is a bug, or if there is a caching issue, or what, but it was getting very annoying yesterday.

As I said, it has since resolved itself, but I just wanted to post this in case anyone else has had the problem and or start a history for the developers if it comes up for other users later.

I’ve seen a few reports of syncing issues between the PC and iOS version.

When digging into these as help tickets, I’ve found Dropbox on the PC is defaulting to “online-only” for the user’s data. That’s causing issues like the ones that macOS Monterey/Ventura users have encountered in the past with that same setting.

This Dropbox Support page explains the settings that a Windows or Mac user can change so that projects are available offline. I’d start there to see if it corrects the syncing issues.

I had to make that change on recently on my Win 10 machine when it stopped syncing changes made using either my iOS devices or Mac.

2 Likes

My Dropbox files on my PC are always stored locally and sync. I don’t think they’re kept on my phone (my iOS device) and it just syncs with the cloud.

The files are and should be stored locally on both the iOS and Windows machine. Dropbox “syncs” by making sure the files on both locations are the same. The symptoms you report look to be, as @RuthS says, incomplete syncs by Dropbox.

Edit: see How to fix Dropbox not syncing and other issues - Dropbox Help.

1 Like

The next time that happens, if it is something you can share with support, the copies of the backup files created before and after syncing on the desktop could be helpful.

Useful data to gather...

There should be these backups by default:

  • The one you get when closing the project on the desktop. That will be what in theory synced to Dropbox.
  • The copy that is created directly prior to internally syncing mobile changes. Such backups can be identified by the presence of a Mobile subfolder within the .scriv folder. This is valuable because it shows the state of the project, as edited on iOS, that was downloaded to the PC. After that point, once mobile changes are merged, the Mobile folder is wiped, no trace of the phone’s state as a discrete condition will remain.

There is a blind spot there in that first point has an “in theory” tacked onto it. We can’t really know what did sync to the phone, only what should have, based on the local state of the project when it was closed. To close that gap, one would need to:

  1. Create a zipped backup from the phone directly after syncing, but before opening it.
  2. Create another backup after closing out the project on the phone (whether syncing before or after isn’t important).

With these four backups then, we can see what should have synced from the desktop, what did arrive on mobile, and then the same in the other direction, as well as how the software interpreted all of the changes made between point one and four. If there is a bug in the internal sync code, for example, we would expect to see a coherent binder file coming from Mobile (showing the moved item where it should be), but it ending up in another position after internal sync. If however there are differences between the pre and post Dropbox transfer, then we know the problem is with the third-party sync somewhere—probably a cache issue as you speculated.

So if it starts happening again, and you can share data with us, that’s the procedure I’d recommend, and the four .zip files we would get the clearest picture from of every notable step along the way while the project is in a closed state.


As for the notion that it was an incomplete sync—lacking a local copy of the file that would indicate binder positioning—that should in theory not be possible. If the Mobile/binder.mob file (mobile Scriv’s simplified take on the .scrivx file) is not present when the project is opened, then sync doesn’t even start, because without that file nothing else in the Mobile subfolder would be safe to work with—that file is as critical to Scrivener’s understand of the data as the .scrivx file. So in other words the symptoms would be: it didn’t sync at all and it would open on the desktop in the state you left it in prior to switching to mobile. You wouldn’t see some things sync, but not other things.

I even tried to simulate a binder level conflict, by removing the Mobile folder from an edited test project (containing both binder movement and content changes), opening it and editing it on the desktop so that modification dates on the desktop binder were newer than the iOS binder, put the Mobile folder back in and synced it—and it worked fine. It threw a warning about conflicts (naturally), but it sorted things out. Basically both binder modifications were merged correctly, at a granular level. The mobile’s changes to the binder order were intact, content edits all present, and the separate binder changes made on the desktop in conflict were also present.

Now what I didn’t try was deliberately moving the same file back and forth over and over between conflicts. Maybe in that case one could see “reversion” because the newer binder is really the older one from a human perspective—but I didn’t bother testing any further as you never mentioned seeing a conflict warning at any point.

1 Like

I did see a conflict warning - sorry that I left that out. I’ll try to gather the date you listed earlier if I see this happen again!

1 Like