The problem, which you don’t seem to understand, is that there are always three different computers involved in Scrivener’s syncing, and three different softwares, of which L&L only control two, and each one of them (computer/software) only knows about itself. The individual computer/software has no knowledge about the others, or what the user perhaps wants the three of them to do together. On top of that, each one is fully capable of being used in isolation, by itself, without including the other two.
Your analogy with the motorcycle is not relevant at all, for the simple reason that a hiccup in the syncing is comparable to running out of fuel, not of having an explosion. You don’t risk getting physically hurt or killed by losing some piece of text you’ve written. You simply have to re-write it.
The simplest way to avoid the risk of having syncing problems, if the risk really scares you, is not to sync. Don’t work on the project from several devices!
As I wrote earlier, I am syncing both DevonThink on macOS and DevonThink To Go (iOS) through a third computer, a custom-configured WebDAV server running on an Ubuntu-formatted old iMac. The syncing is being done in every direction flawlessly, with open documents everywhere. I am pretty positive the Ubuntu machine doesn’t know a lot about either DevonThink, macOS or iOS. It doesn’t even know it’s running on a Mac.
Fellow user of Devonthink here, but not as a user of its sync capabilities. Were you on the forums when they launched the sync service? Lots of frustrated users registering complaints at the time, due to what seems to have been a very complicated system involving sync stores, etc. I think things have improved since then. My point is that it was not seamless, and required quite a lot of user intervention to set up, as far as I could tell.
I’m curious as to how Scrivener is different, in terms of requiring user management? Genuine question, as I have never had a problem with Scrivener sync. I just have it set up to close and back-up after a period of inactivity on my Macbook, so that if I ever open the iOS version, I’m not generating potential conflicts. Would that work for you?
There’s been a lot of discussions about the sync issues on these forums over the years, free to search. if you do, you’ll find that Scrivener’s document format is in no way similar to DevonThink’s database. There are reasons why Scrivener’s file format is the way it is (relating to characteristics that KB has decided are his priorities) and there has been a LOT of work to redo the file format to accommodate syncing to iOS in the most resilient way possible.
My point is, you can point at other software packages all you want, but you’re not comparing apples to apples when you do so. Sync isn’t a one-size-fits-all problem to solve. The world’s foremost expert at sync in Scrivener (KB) has spent a long time defining the problem, defining the edge cases, and coming up with workable solutions that fit within the constraints of what makes Scrivener what it is. It’s a bit presumptuous for ANY of us (since none of us have access to the code) to just snap out fingers and say, “Fix it.”
Now, if people can show that there is an actual bug in the sync routines – demonstrate the bug in a reliable way, so that KB can troubleshoot it – then things can get better. But unless that happens, chances are good it any sync-related losses are due to user error of some sort. One of the whole design concepts behind Scrivener is that if something breaks, you can always go into the package and find the RTF files with your data in them without having to have fancy tools or special knowledge of the file format. You can’t do that with DevonThink or any other database, for that matter.
I don’t think I was on the DT forums when they launched the sync features, but I believe I was using DTTG on iOS from day one. Setting up the sync stores is somewhat complex, yes. You have to do more than click a couple of buttons, especially if you’re using a custom WebDAV solution like I do. Since I set it up, however, I didn’t have a single hiccup with sync in two years, whether via Wi-Fi or cellular, and I’m running 3 databases of around 20 gb each with thousands of documents. This has become my reference for quality in the matter, that’s why I keep citing it. I don’t know the devs.
This is exactly what I’m doing, after having increased the number of backups in the preferences. It’s working, I’m not saying it doesn’t. It’s just the potential loss of data if I’m not careful and the overall performance (much, much slower than DT) that I could live without, that’s all.
I wouldn’t equate suggesting that a feature could be improved with snapping fingers and saying “Fix it”. I don’t snap fingers at people I don’t know.
This is the point I’m trying to make for the last four posts here: sync-related losses should never be the result of user error. Scrivener itself boasts — and rightly so — that you never need to save anything while you work. Data should be immune to user error, unless the user actively decides to wipe it. This is a general idea and is not limited to Scrivener. Software should keep the data intact no matter what incident occurs: power outage, network issues, alien invasion, a general election, whatever. The only loss of data should occur when a user presses Backspace, deletes a file or empties the Trash.
Unless I misunderstood you, I believe you are mistaken. You can right-click any DT database, look inside the package and retrieve anything you want. This is a very important principle of DT. You lose some of the metadata, but you never lose the data. Your RTF or TXT or whatever is always there, on disk.
The fact that you even know what a WebDAV server is puts you several steps ahead of the typical user. Any alternative sync solution must be able to work with a commercial service like Dropbox or iCloud.
As I noted upthread, I love DevonThink to Go, but I wouldn’t describe its synchronization as “flawless” at all. There are also important differences between DevonThink databases and Scrivener projects, most notably the relationships between the component files.
If you had read the links, you would know that people are experiencing unrecoverable data loss on devices that aren’t running the beta, but are simply sharing an iCloud location with a device that is. One of the challenges of any synchronization service – and the reason why I don’t recommend relying on them as backups – is that errors on one device can propagate very quickly.
My point was not to get into the relative merits of various services, though, but to observe that seamless, bulletproof synchronization is not nearly as common, or as easy to achieve, as these threads sometimes suggest.
The thing is, under some circumstances, Dropbox can erroneously believe that the user did exactly that. Version A of a project has a file. In Version B, the file is gone. If Dropbox believes that Version B is “current,” then it will believe that the user wanted to delete the file.
Cirrocumulus said that the issues are related to beta releases
You seem to be saying that the people are experiencing unrecoverable data loss on devices sharing an iCloud location with a device running the beta release.
So what he said is correct: the issue is related to the beta release.
The chances are that most iCloud users only connect to devices that they own, and most iCloud users are not going to run the risk of running beta software. (And if they are then they should be savvy enough to back up their stuff).
I’m afraid we’re going to have to agree to disagree on that one. I was pointing out that highlighting beta software as an indication that syncing is a massive unsolvable problem doesn’t really carry that much weight, which is what the message I quoted was stating. You’re expanding it to the wider argument that has been carrying on here for years:
Everyone here has suffered some sort of computer mishap, so everyone knows it’s important to back up your work.
I think the problem is that most people here have also experienced syncing that works without a five step process and a lingering sense of uncertainty, which is why this keeps coming up time and again.
I did not say that synchronization is an unsolvable problem. I did say that it is a hard problem and that many companies – including massive companies with much larger resources than Scrivener – sometimes have trouble getting it right.
And that, because synchronization is a hard problem, users should understand that a perfect, fire-and-forget solution does not exist, and therefore should make sure that their work is also backed up through other means. Maybe “everyone knows” that backups are important, but the number of people who actually act on that knowledge sometimes seems depressingly small.
I have experienced syncing that is allegedly easy. And I have also experienced the chaos that results when it inevitably goes wrong. One of the core values of Scrivener is that I can always tear apart the project format, without any special tools, and salvage my writing if I really need to.
I think the problem is that a lot people expect their devices to understand what they are expected to do, and to excute this without any time-lag, and this is the reason why this keeps coming up again and again.
Syncing in Scrivener doesn’t require a “five step process”. It just requires a bit of patience on the Mac/PC side, the length depending on the WiFi speed, and a tap on an icon and a bit of patience on the iOS side, again depending on the WiFi speed.
Do you have any constructive suggestions for how the user can be forced to show this patience, and to stop them from putting their Mac/PC to sleep before the DB app has finished syncing, and to stop them from switching app on their iDevice in a way that causes the iDevice to remove iOS Scriv from working memory before they have synced with the DB server, and for this to be done in a way that still enables the user to actually do all of this if they really want to go on without complete syncing?
