Scrivener iOS syncing via Dropbox continues to crash the app

[drmajorbob]

There hasn't been a fix for the problem, but it seems it's related to the length of the path for a particular file being synced, and a few people have got around it by shortening filenames and shallowing hierarchies.

So, assuming that this hasn't already been mentioned in the last 22 pages, has anyone tried the following:

1. Take a project that is not syncing and make a copy of it.
2. Start with the longest path in the hierarchy (could be a really deep path structure or a really long file name or both) and remove it.
3. Remove the Scrivener app from Dropbox sync and add it back in again.
4. Try syncing the project.
5. Go back to step 2 (Repeat with the next longest path.)

I'm wondering if you get to a point where the project will eventually start to sync.

a) All pathnames in the project structure are the same length (within half a dozen characters).

b) We have NO control over pathnames. They're unrelated to document names in the Binder.

Here you see typical documents:

Screen Shot 2019-12-30 at 11.03.13.png (510.66 KiB) Viewed 1078 times

[drmajorbob]

Can someone explain why iOS Scrivener can't trigger a Dropbox update of the project all in one go ... WITHOUT making a list of the files?

How is it supposed to know what files have changed? Keeping in mind that there may be changes to *both* the local and the server versions, and users expect Dropbox to keep track.

Katherine

I could ask, "How does Dropbox ever know what files have changed?"

However, I *think* I perceive the hidden context of your answer. Here's a guess I gave users on a FB group I moderate:

"To your point about the API, I think the issue is how to make iOS transfer project files from Dropbox in the cloud to internal storage on the phone or iPad. If it were possible to simply pass a pointer to the project folder, and iOS would go through all the files and subfolders on its own, copying them to local storage if newer, copying the other way if older, things could be easy. That would require iOS to use Dropbox API calls in a complex way ... and why would Apple want to take on that task?

Until the Files app came along in the past 6 months or so, it was well-nigh impossible to directly access files on iOS. Apps could do it, but they had an iOS API to deal with. Every API has limitations, and Apple doesn't like making it easy to mess with file structures on their devices. There's a reason Literature & Latte hired and fired three (I think) developers before Keith Blount took over developing the iOS app himself, and I'm sure there's a reason he did it via Dropbox, not directly through iOS.

The Files app made things a bit simpler, but does FILES have an accessible API Scrivener can use? I doubt it. The solution I posted yesterday uses Files MANUALLY."

[kewms]

"To your point about the API, I think the issue is how to make iOS transfer project files from Dropbox in the cloud to internal storage on the phone or iPad. If it were possible to simply pass a pointer to the project folder, and iOS would go through all the files and subfolders on its own, copying them to local storage if newer, copying the other way if older, things could be easy. That would require iOS to use Dropbox API calls in a complex way ... and why would Apple want to take on that task?

This is essentially what iOS Scrivener does: it downloads the file list from the server, compares it to the local list, then uploads/downloads as needed to make the two lists match. And yes, doing so involves deep entanglement with the Dropbox API.

The short answer to the perennial "why won't iOS Scrivener use iCloud" question is that the iCloud API does not currently allow the level of access to individual files that Scrivener needs. The Files app is a step in that direction, but only a step.

Katherine

[Silverdragon]

@Rayz,

Very interesting info! Hierarchies and filenames—hmmm…

This makes sense as the Scriv 3 project structure added a layer of internal hierarchy as well as a LONG filename (a UUID) for each file in the Binder. If the bug is indeed related to filename length and hierarchy depth, then folks still using Scriv 2 Mac or Scriv 1 Win should see this problem less often. (No UUIDs, shorter hierarchy.)

I'd like to add this information:

99% of the filenames internal to the project are not under user control. The hierarchy internal to the project is not under user control either. (What you see in your Binder bears little resemblance to the on-drive structure).

You could rename each project (by using Save as…) to something very short. Don't bother to rename anything in the Binder because those names aren't used as filenames. Don't bother to rearrange your Binder to shorten hierarchies as they don't affect the structure Dropbox sees. You could also change your sync folder to a folder to a top-level Dropbox folder with a single-letter name (like "S"), thus shortening both pathname and hierarchy (as compared to /apps/Scrivener).

Hope this helps.

EDIT: I see @drmajorbob already provided most of this info, with illustration. But the shorter project name and top-level single-letter folder might still be of some help.

[derick]

Hmmm....in my case & I think some others in this thread, the projects that crash actually originated in Scrivener 2 or 1.

[Silverdragon]

If they've been converted to Scriv 3 format then origin Scriv version doesn't matter. The conversion process would have added the hierarchy depth and the UUIDs as part of pathnames—if that's truly the trigger.

[kewms]

Hmmm....in my case & I think some others in this thread, the projects that crash actually originated in Scrivener 2 or 1.

Hmm.

What happens if you use the Import -> Scrivener project command to import the converted project into a new, blank, Scrivener 3 project?

It shouldn't matter. But this addresses the possibility that there's some kind of artifact from the conversion contributing to the problem.

Katherine

[kewms]

a) All pathnames in the project structure are the same length (within half a dozen characters).

b) We have NO control over pathnames. They're unrelated to document names in the Binder.

However, it's possible to nest as many folders as you like, as deep as you like, inside the Dropbox/Scrivener sync folder. Do people who are experiencing the crash have a more complicated folder structure than people who aren't?

Katherine

[Rayz]

a) All pathnames in the project structure are the same length (within half a dozen characters).

b) We have NO control over pathnames. They're unrelated to document names in the Binder.

However, it's possible to nest as many folders as you like, as deep as you like, inside the Dropbox/Scrivener sync folder. Do people who are experiencing the crash have a more complicated folder structure than people who aren't?

Katherine

Might be worth looking into, but drmajorbob's project looks fairly shallow (though I don't know what' going on in the closed folders).

[Rayz]

@Rayz,

Very interesting info! Hierarchies and filenames—hmmm…

This makes sense as the Scriv 3 project structure added a layer of internal hierarchy as well as a LONG filename (a UUID) for each file in the Binder. If the bug is indeed related to filename length and hierarchy depth, then folks still using Scriv 2 Mac or Scriv 1 Win should see this problem less often. (No UUIDs, shorter hierarchy.)

I'd like to add this information:

99% of the filenames internal to the project are not under user control. The hierarchy internal to the project is not under user control either. (What you see in your Binder bears little resemblance to the on-drive structure).

You could rename each project (by using Save as…) to something very short. Don't bother to rename anything in the Binder because those names aren't used as filenames. Don't bother to rearrange your Binder to shorten hierarchies as they don't affect the structure Dropbox sees. You could also change your sync folder to a folder to a top-level Dropbox folder with a single-letter name (like "S"), thus shortening both pathname and hierarchy (as compared to /apps/Scrivener).

Hope this helps.

EDIT: I see @drmajorbob already provided most of this info, with illustration. But the shorter project name and top-level single-letter folder might still be of some help.

Yes, I read drmajorbob's comment. Shame. I thought it might be something that would be easy to test out.

[lunk]

Even if individual path names are only half a dozen characters, having a deep folder structure could add quite a lot of characters.
My own complete path to the sync folder and the project to sync, on the Dropbox server, is:

Scrivener projects/Scriv active projects/projectname.scriv

... and the project with the longest name has 59 characters plus .scriv, so in total 99 characters in the folder name/path.

[drmajorbob]

Even if individual path names are only half a dozen characters, having a deep folder structure could add quite a lot of characters.
My own complete path to the sync folder and the project to sync, on the Dropbox server, is:

Scrivener projects/Scriv active projects/projectname.scriv

... and the project with the longest name has 59 characters plus .scriv, so in total 99 characters in the folder name/path.

I wouldn't keep inactive projects ANYWHERE in that hierarchy. They use space on your iOS device even if you never open or sync them. Hence, I have no hierarchy below ~/Dropbox/Apps/Bobby Scrivener/

I haven't seen the sync crash, either, but I don't claim a simple file structure is responsible for it.

[lunk]

No they don’t, because it is the folder Scriv Active Projects that I sync, not the parent folder.

[drmajorbob]

With 345 posts in this thread so far, does that mean less than 345 users have complained? Subtracting duplicates, Literature & Latte posts, and posts like mine, is it less than 50 users, perhaps?

Does that mean the problem is incredibly rare?

[NoHope]

With 345 posts in this thread so far, does that mean less than 345 users have complained? Subtracting duplicates, Literature & Latte posts, and posts like mine, is it less than 50 users, perhaps?

Does that mean the problem is incredibly rare?

That’s something I’ve wondered. How many actual cases.
I’m not trying to minimize the impact it has on those with the issue, just wondering how large a sample have the L&L team to try to lock down the cause?