This is a topic that comes up semi-regularly, and I’m wondering if there has been any further thought about this question? I’ve recently been thinking about the .scriv file format, a file acting as a folder for other files, and how cloud based storage mangles .scriv files. I’m frankly tired of having one one option for cloud-based storage for my scrivener projects, and am hoping there are Dropbox alternatives after all this time. (Google drive is a no go, because: Google.) I’ve been looking with no good results, and I wince as I am about to post this question for fear of the replies I expect to see. Nevertheless, fingers crossed, here goes … >post<.
Pretty much everything you’ve heard is a myth, basically. So here’s the short and simple:
- No, Dropbox is not “safer” or more “reliable” than other services.
- We do not recommend it over other services.
- We certainly do not only support it, or strongly advise that’s all you use (you will see people saying stuff like that). Nothing anywhere in our documentation or website states that, or even subtler statements. I think the closest we may come to it is a line like, “Many sync services, like Dropbox, are safe to use with Scrivener…”, which obviously states the opposite anyway.
- iCloud Drive works fine, contrary to what you’ll read elsewhere (people saying it’s “not supported”). It doesn’t work fine on Windows because Apple.
- OneDrive works fine, but not on macOS, because Microsoft.
- Packages do not exist. It is a fiction that your Mac presents to you while using the front end, like Finder, or in file open dialogue boxes. There is nothing in the data that makes it something special, mysterious, fragile, or in need of special handling.
With the exception of Google Drive being a little weird sometimes (to the extent we don’t recommend it), there is no wide-spread “incompatibility” with cloud sync. As a concept this is not something that makes technological sense, because in fact there is nothing about a folder acting like a file on your personal computer that changes the fact that it’s merely a folder with files in it, everywhere else (even on your own computer, in contexts that don’t involve the front-end GUI). That very same project, when loaded on Windows, doesn’t look anything like what you see, and it works just like any other folder with files in it—and that’s what a cloud sync service sees too.
Everything that can sync folders and files should sync Scrivener projects. Anything that doesn’t do that properly is not worth using in general, as it should be suspect for any level of file management across the board.
So with that established, you can see how a lot of these myths don’t make any sense. I’ve used this example elsewhere, but some of them are as silly as saying you can only use Seagate hard drives to copy Scrivener projects safely, or that Sandisk drives are “not supported”, or that L&L strongly recommends only using LaCie. If you know how hard drives work, and how file systems work, none of that makes any sense. File sync, as a technology, is a lot more complicated than hard drives, there are many more moving parts of course, but they all essentially work the same as disks do when you copy data around.
Important caveat: a lot of mainstream services have “smart sync” of some sort, and nobody should be using that, period. It’s especially a bad idea to use it with anything that needs more than one file to get a job done, but it’s a terrible setting overall (everyone that uses it has compromised local backups as they don’t actually have ownership of all their data). Dropbox is just as guilty of this, these days, and evidence of that can be seen regularly, with the “help my whole project is blank” reports.
So again: there is no such thing as a “.scriv format”, when it comes to how file servers, networking, hard drives, or file syncing works. It’s just not a thing. There is zero difference between a folder that has “.scriv” typed onto the end of it, and one that does not.
If you want to make sure though, here is a checklist to help you evaluate a service.
Beyond the dirt basic fundamentals above, there is a lot of nuance, and a lot of ground for debating which services are subjectively best. There are issues like how iCloud Drive tells you nothing about whether it is working or not unless you are staring at the icon of the thing in Finder that is being uploaded. There are issues with how Dropbox’s default setting keeps your projects offline. Some might prefer a client, while others prefer it fully embedded in the file manager. There are lots of little things we could debate over, and some even might be more relevant to Scrivener users than others, but the important thing is that almost all of them are fine to use for what they do.
As for an alternative? I use Tresorit. The prices are reasonable, and I like how it lets me sync whatever I want, rather than having to use this mammoth dumping ground centralised folder concept that many use. It works fine with Scrivener, naturally. It syncs folders and files after all. 
5 Likes
Now I (and possibly others) are confused. L&L staff (as far as I remember without wasting time searching) have said almost the opposite in the past.
My understanding is that Dropbox is the only one that correctly syncs where iOS is in the mix (talking projects here, not .zipped files).
I also in the past have mentioned other services (Sync) and L&L team have cautioned against from memory.
I have a great deal with Sync (mentioned it previously - GDPR compliant, not owned by any company from Trumpistan) and where iOS is not in the mix would prefer to use Sync if it is not a risk. Will have to investigate further.
2 Likes
Indeed. I have seen exactly the same opposite messaging that you mention on this topic from L&L in the past. In fact one of the live streams about cloud syncing repeatedly stated that Dropbox was the only option for iOS synchronization, and I recently asked about Sync adoption for the iOS version and was met with an equally salty reply from an L&L branded account. And I even just recently had a .scriv project go sideways using Sync between two different Macs. (Again, I’ve been a Scrivener user for 15 years, and I do file sync operations in post-production for huge studio streaming shows and movies, so I’m pretty confident I’m not doing anything cuckoo here.)
My solution is to now just work locally and copy files to whatever sharing service, and only after they are zipped. I always thought it might be a good idea to use the .zip file format as an intermediary file format for Scrivener cloud-based workflows, but that wouldn’t make any developer happy, having to license other code (which I think would apply to .zip).
Nevertheless, you are spot-on about the confusion. I am now doubly confused.
I don’t know, I’ve always said precisely the above, over and over and over, for years now. Other people may have different opinions—like I said there is a lot of room for opinion on the matter. I prefer security and privacy over most other factors, but others might prefer convenience.
iOS is a completely different universe than how most systems sync, but I would tentatively say you’re mixing up methods in thinking that. For example, the only way to get a synced project from Tresorit into Scrivener is to compress it in Files.app (long tap) drag the .zip over, and decompress it in Scrivener’s folder. But the exact same thing is true of Dropbox, if you use it through Files.app.
What you’re referring to, I think, is a dedicated client in Scrivener for iOS that uses Dropbox’s API to mimic what desktops do when syncing.
That’s decidedly different than saying only it correctly syncs. The main problem is Apple’s Files.app being trash at copying whole folders on off of sync plug-ins when dragging and dropping. If it did that better, you wouldn’t need the .zip workaround.
But to be clear, none of that has anything to do with syncing between normal computers. iOS is special in how difficult it makes a lot of things like this. But I don’t think for the most part that any one sync provider is better or worse on iOS. They are all using the same kit to integrate with Files.app. The problems are in the kit.
I also in the past have mentioned other services (Sync) and L&L team have cautioned against from memory.
There is a list of advisories on our knowledge base. Only Google Drive wins the “avoid at all cost” badge. The other advisories outline settings that should be tweaked—and Dropbox is included among those. So if you’re going by official statements of caution in using default settings as a way of saying cautioning against, then Dropbox is on the list. But I wouldn’t conflate those two things.
2 Likes
As I note above, iOS is its own special world of pain, but most of that has to do with how the OS is designed rather than sync itself. I didn’t see anything about it in your initial question, so none of my response had anything to do with it. I’m talking purely about sync services you install or activate on your computers, and use to copy data between them.
The important thing to take away from iOS is that the only reason we use Dropbox for the built-in client is because it was the only service that had an API that let us build a local client in the software, for it. I believe these days there may be more that could be made to work, but most of them are pretty niche and it would be hard to justify the months of development it took to make such a thing. That isn’t a statement of reliability though, purely one of capability and feasibility.
As to the rest, you’ll have to pardon me. I think of iOS about as much as I think of my toaster. I barely use it, my phone is off 99% of the time. And so when I’m looking for good sync tools, it has nothing to do with the equation.
I do think a lot of the myth surrounding packages and reliability and all that probably does spring up from people who use iOS though and cannot fathom not using it. You game of telephone that enough, and stuff starts coming out like, “only Dropbox is supported”, meaning everything and everywhere, when the original statement was a whole lot more narrow.
And I even just recently had a .scriv project go sideways using Sync between two different Macs.
You could probably dig into what happened, but on the whole you can do that with Dropbox too. As I said above, the forum is filled with projects needing repair or fixing because of Dropbox. There is, to a degree, an unavoidable amount of risk with all sync services, and making a mess can happen even to the best of us. I’ve certainly done it (I’ve done it with a plain old folder of .md files, too!).
Now what might be a fair statement is that such risks will be amplified when you’ve got a program that uses 4,584 files to get a job done, but that’s true of even FTP. Any increase in transactions will elevate the chance of something going wrong somewhere. So using .zip reduces that to a single point of potential failure.
I’ve stated it many times before in the past, but I’m the sort that does prefer to reduce risk over convenience. So I do prefer .zip transfers. I prefer them when using file sharing over LAN too, though, or even thumb drives. It’s just faster to use one file when copying mass data around.
2 Likes
One other thing to say, and that is going through forum history can be a bit awkward. It is true that for a time these myths did impact official support and even the wording in the FAQ. We’ve gone through and fixed that in the years since, but historically there was a time when you could find official statements like that, and that’s probably what you’re thinking of.
Thing is, if you go back far enough into the past you’ll find strong warnings against using Dropbox! This was back when it was still new, and pretty much the only game in town worth speaking of, but for many years the going fallback advice was: don’t use Dropbox at all!
By and large it was because we didn’t understand what was going wrong, and back then Scrivener didn’t do a really good job of protecting against casual sync conflict errors. It was in fact a point of awkwardness even as late as when the iOS version came out, because we still had a lot of ongoing inertial advice warning people off Dropbox entirely—yet here we had this mobile version that used it. 
So, you kind of have to take historic advice with a grain of salt. Scrivener’s modern project format is designed with multiple redundancies that protect it against sync failures, and safety nets to help you recover, when they happen. What was once stated as fundamental problems, has since been discovered to be solvable.
Services change over time, too. There was a point in time when Dropbox hands down had the best technology, and the best track record for always copying things correctly and swiftly (and we said as much). But that was before smart sync, and before adopting Apple’s infrastructure for sync storage. These days it is much like everything else that sits in that mainstream hump.
2 Likes
I just want to emphasize @AmberV’s point that iOS is a separate thing from either desktop platform. In particular, (1) the platform itself is much more opaque about what’s going on, and (2) iOS Scrivener is tied to Dropbox in a way that the desktop versions very much are not.
So, in reading forum advice (or asking forum questions) it’s very important to be clear about exactly what platform(s) is involved.
5 Likes