Remedying a timeout problem possible in syncing with conflicts

I generated what was actually a Conflict Files situation last night, no doubt by forgetting to sync a change on the laptop before opening the project on iOS, just as Keith suggests. Much likelihood of that happening working too long, with both in the same room. Recovery should be easy…but not this time, which is by the way the only instance of conflict I’ve seen so far.

The problem was that I couldn’t see this: no Conflict Files yet on either, and Scrivener iOS failing every time to complete a Sync, with thee files remaining. You could watch it time out, no matter what I tried such as deleting the sync cache, etc…

Finally I thought about it, and removed a large pdf which had been added to the Wndows version, while leaving a possibly also large Pages->Word file added from the iPad – depends how it actually handled the pictures in it.

As soon as the PDF was out on Windows (importantly, delete to Trash, but also Empty Trash so it’s really gone), then Scrivener iOs picked up, pulled a lot more files which had not been indicated before (possibly from other projects), and nicely completed the Sync, leaving me the present of Conflict Files which included the pdf. And, the pdf was back in place on the iPad, untouched.

I did a dance which was not really correct response, it being very late, butgot the project free of conflict, which works and syncs fine. I had copied the full Conflict Files folder, and will later cross-edit. The actual changes will be small; in fact mostly font changes as that was what I was doing in parallel, implementing a Fonts folder so I can use favorites and others occasionally.

I can’t say why the pdf was involved in conflict, as it never changed, and it was present on iOS once conflict showed.

The pdf size is even bigger then I reckoned: 6.5+MB. Also, it is in the project twice, as I look at folders on the laptop. Furthermore, the Pages-Word rtf is 7.1+MB, so we are looking at 20MB potentially of file loading, to force this timeout. I removed only one of the pdfs, not realizing about the other, and to take the other view, this might have been the only copy in conflict. Could well explain why I seemed to find the pdf present before remedying conflict, as above.

In any case, I think the timeout that was hit was too short for this conflict, with sizes that easily could be had in the wild [wild out there].

I think I would suggest that instead of a hard timeout, Scrivener iOS could present a choice each time it’s run into: Do you want to stop and go back to assuring Dropbox is complete, or do you want to keep trying for another (equal) period. To implement this, you’d have to assure that you didn’t fatally interrupt the Dropbox download, naturally, but otherwise should be easy and sensible to meet, which we hope not so many do, but rich document builders possibly will.

Did I say iOS Scrivener is a remarkable creation? Now I am sure I did…

All the best from here,