drmajorbob wrote:Regardless of its origin, a Scrivener 3 project has its documents a level lower in the file hierarchy than before, in folders with 36-character names. Even if the pathname length doesn’t matter, you’re searching those folders, which didn’t exist in Scrivener 1 or 2. That’s a more complicated loop, potentially. (Visually at least, the file structure is far more complex.)
More complicated probably isn’t how I would put it. The loop just gets a list of files at one level, notes which are folders, and then works through the list of those, and on and on until it runs out of folders to scan. The complexity of this process does not change if you add an additional layer of hierarchy—it merely changes the length of the process. And to reiterate, that
is the only part of the process that iOS is giving up on: a recursive trawl of a relative basic (in the grand scheme of things) folder hierarchy. This problem is not even technically within the realm of synchronisation
sidderke wrote:Some people are here saying it especially happens with projects that started with Scrivener 2 and were upgraded to 3.
The long delay was a matter of poor optimisation in Dropbox’s server side and has largely been cleaned up at this point (they could still do better, but it’s nowhere near as bad as it was). As I’ve expressed before in this thread, it is extremely unlikely that a server side Dropbox optimisation issue
has anything at all to do with a specific version of iOS running out of RAM (or at least thinking it has run out of RAM). I don’t understand why, four or five pages later, it is being posted again as maybe still being an issue.
As Katherine notes, there are a lot of factors I see being reposted as maybe being issues that aren’t actually issues. We’ve eliminated most of what seemed to be patterns, early in the process. All we really know is that iOS 13 has a fickle resource management routine that only backfires in some contexts (where context is a nebulous concept that could span from extremely specific hardware characteristics that aren’t model related, to installation patterns, to settings made, to things I’m not even thinking of here). That’s about it!
ThomasRabenstein wrote:Whether my statement was specific enough or not doesn’t really matter. It’s starting to feel as if the problem is considered minor, and that it’s not being treated as a priority because it seems to only affect a minority. That disappoints me.
There is an extremely important difference between not having enough data to solve a problem, and every indication of the problem being on the OS side—and not treating it as a priority
for… whatever reason (I can say that in general we don’t rate bugs on commonality but severity, so your assertion that we would let something slide because only some people experience it is false). The latter is a speculation made on your part, and I would say is clearly rebutted above in my listing of posts. We have given the matter as much priority as we can—far more than we have many bug reports in fact. But after a certain point, without any data, what you’re suggesting we continue doing is what we would all refer to as banging one’s head against a wall. It serves no purpose.
There are still more avenues for gathering data, but most of them are so extreme, to date nobody has tried them (nor do I blame anyone for not doing so). Spending half a day backing up, factory resetting, testing and then restoring your device is a lot of work. But it would serve to provide a valuable look into the matter of context, particularly if that clean slate device works
, and then can be shown to stop working as its original level of functionality, both in installation and configuration, is gradually restored. It’s the kind of test we’d do ourselves if we could.