Potential problems with Dropbox?

A wonderful morning to FINALLY see the iOS version available. Huge thank you to Keith and crew for making this happen.
I’ve been using Scrivener for years and it is essential for writing book. One of the absolutly best applications on my computer.

Don’t want to raise alarm as I have NOT had the following problem with the new iOS version. However in the past I used to keep my Scrivener projects in Dropbox. On two occasions I opened Scrivener to an “Index Rebuild” dialog, and then found numerous text files in a “Recovered” folder at the bottom of my binder. This required many hours of tedious cleanup as I didn’t want to throw any potentially unique text away. After the second time I got in touch with tech support who gave me the following reply (below). In short some kind of sync issue with Dropbox, caused Scrivener’s index to get messed up. A year ago I moved my Scrivener project OUT of Dropbox and have not had this problem since.

In a perfect world, we would all safely quit Scrivener after a session (with backup on, of course) and then let Dropbox compleatly sync before shutting down/sleeping our computers. But often times (usually) this is not what happens. For example I may also have a 2GB Photoshop file in my Dropbox queue ahead of Scrivener, etc.

What will happen to our projects if Dropbox is not allowed to sync completely and then we go to our iOS version and perform a sync?
Are there any other potential situations which could trigger this Index Rebuild/Recovered files issue?

Thank you.
(Intentionally posting to the iOS thread as I know this is where all the action is today :slight_smile:

Here is the response from tech support last year:

There are numerous safety nets in place, but the simple fact of the matter is that if you take two different projects and smash them together and try to load the result—yeah, all bets are off. As to the specifics, if Scrivener detects this situation while you are loading the project it will do its best to let you know and give you a chance to wait. If that check failed it will do its best to resolve the obvious stuff, and for anything it would take a human to resolve, you’ll get duplicate “conflict” copies in the binder—kind of like the “recovered” thing but a bit nicer than that. So in a planned-for worst case you’ll have some fixing to do.

Alternatively you can just use the iOS version natively and copy projects on and off of it using a file management tool like iTunes. That is the approach I take (more often I use AirDrop because that is super easy) as I don’t use any kind of “cloud” services, myself.

You made me curious about this so I tried AirDrop for the first time today; hadn’t used it with anything else before. It worked well for/between Scriv and iScriv. It does take a bit more care as compared to iTunes File Sharing, in that you have to be conscious of the incremental number changes in the file title.

Thanks for the prompt. It’s another good option to get things done.

I got this behavior when I tried adding a scene to a folder on my iPad. The file I added was put in the Recovered Files folder.

This is very worrisome. If I can’t add new files from my iPad, the value of the program is severely limited to me.

Did you remember to save, i.e. tap the save/update/sync circular arrows button before leaving Scrivener?

If you haven’t fully synced, Scrivener should show you a warning telling you that it seems not all files are synced yet, and asking you if you want to continue anyway. If you ignore this warning and go ahead and open the project, you could well end up with conflicts or recovered files. Documents are put in the “Recovered Files” folder at the bottom of the binder in the Mac version when it finds text documents inside the project package that have no entry in the binder. This could happen if you didn’t complete the sync so that the text files had been downloaded but not the binder file. This is one of the many sync issues Scrivener has to deal with (hence manual syncing on iOS), and of course, there is no way for Scrivener to show the project as you expect it if the project isn’t fully synced. If the files aren’t there, Scrivener can’t show them.

As I say, it does do its best to warn you about this, though.

KnoxHarrington - did you see such a warning in the Mac version? When you returned to the project did you make sure you synced in the Mac version by going to Files > Sync > with Mobile Devices (or clicking on the Mobile Sync toolbar icon)?

In fact, however, “Recovered Files” has nothing to do with the iOS version. If there are sync problems with iOS, they get added to a “Conflicts” folder. “Recovered Files” are only created if there is a sync problem between desktop machines, I think.

All the best,

It looks like the problem may have come in because I still had syncing with an external folder turned on. It works now after clearing that out.

However, this brings up another issue. I really would like the ability to have both enabled for backup redundancy, if nothing else.

I’m attaching the error I got. It looks like it’s related to the sync with the external folder, not the sync between the iOS and Mac OS X apps.Screenshot 2016-07-24 12.17.27.png

Recovered files are more often a case of the project being out of sync with itself, which is nearly always caused by having the project on multiple computers and performing edits on these machines without keeping them up to date with one another. Keep in mind that Scrivener 2.8 is designed to get out of sync with the mobile version. It however has no such designs for when the core project itself gets out of sync, other than to do its best at recovery like this, by importing the files that have no meta-data in the project and putting them in a recovery folder so you can sort it out.

That won’t happen with iOS, or the external folder sync feature for that matter. This is the sort of thing that happens if one forks a project and then tries to have third-party services like Dropbox merge the two forked projects together into one—something it cannot do as it has no understanding of how to properly do that, and Scrivener cannot do it because it doesn’t know enough to make sense of the duplicated conflict files created by Dropbox.