Syncing to Onedrive

Thanks, that’s very helpful. I had a total nightmare with Dropbox a few years back, but I’ll take another look at it.

Having looked at Dropbox, it’s disappointing that that is the only option for Scrivener. It seems pretty expensive compared to Onedrive. How unreliable is Onedrive for Scrivener?

You didn’t answer my question. What does ‘block-moved them’ mean?

Dropbox is not the only option for desktop Scrivener, but, based on feedback on these forums from Windows users, it is recognized by L&L as one of the more reliable options. But careful users have used other services as well.

How large are your Scrivener projects that you need to go to a paid level?
For my Scrivener projects, I use the free level of Dropbox, which supports up to 2 GB.
For everything else on my PC, including Scrivener zipped backups, I use OneDrive.

I have experience with Dropbox, Onedrive, Google Drive, and iCloud on Windows PCs for syncing various types of files. My experience and feedback is only for Windows; Mac users will have a completely different experience.

I would never rely on the Google Drive or iCloud apps on Windows for syncing anything important and/or complex.

The Dropbox app is head and shoulders above the others in transparency and responsiveness–it’s easy to know which files were synced and when they were synced, and it always syncs when I expect it to. Still, even with Dropbox, I am very careful to monitor that syncing has completed, that my wifi is consistent, and that my backup system is thorough.

If for some reason the Dropbox service became unavailable to me, my next choice for desktop syncing would be Onedrive. Yes, I would trust Onedrive with my desktop Scrivener projects. I have seen a number of posts here from Windows users who successfully do so. However – I would also be very very careful to monitor syncing, wifi stability, and my backup system.

My advice –

if you feel like you’re the type of person who will apply a consistent level of care and attention to a process like syncing, then give OneDrive a try. (As already stated, I feel Dropbox would be a better choice, if you can fit within the storage requirements of the free level or can afford the paid level.)

But if you expect syncing to ‘just work’ without any effort on your part, then don’t do it at all. Consider another method of sharing projects between PCs.

Best,
Jim

3 Likes

I highlighted a bunch of files simultaneously and dragged them to the Onedrive folder.

More than 2 GB.

I am open to alternatives. The one in the article does not seem to be ‘without effort on my part.’ It appears to require quite a bit more effort.

You didn’t answer my question: Just how unreliable is Onedrive for Scrivener?

Dropbox isn’t supported in any special way on PCs and Macs. Scrivener always works on the local hard drive and does nothing at all to do with syncing projects anywhere, other than a bit of checking for conflicts (which works the same no matter what sync service we use). Some of the sync services currently have a tendency to “save space” by keeping files online only (off the hard drive) until needed, which doesn’t work well with Scrivener projects.

1 Like

If you moved files, then you might indeed have a problem and damaged your projects.

If you moved folders, specifically the Scrivener project folders ending in .scriv, then the block move should have been fine, because all of the requisite files/folders would have been moved intact within the project folders .

The problem with syncing is that it is very easy to become passive and let the syncing app do everything. Posters who become passive users of sync are more at risk of breaking their projects.

The alternatives do require more active work on your part, but the risk of breaking your project is far less than with syncing.

Have a read of my Syncing post linked upthread, which describes some of the ways syncing can break your projects, as well as syncing best practices. A sync issue can be insidious, in that you might not notice it immediately; in that scenario, if your backup system is not robust, you might permanently lose data. With the alternatives, this is far less likely to happen.

Actually, I did answer it to the best of my ability and experience: Onedrive is less reliable, transparent, and responsive than Dropbox, but better than Google Drive and iCloud. If Dropbox were unavailable, I would use Onedrive to sync my Scrivener projects, but I would be extra careful and vigilant.

ETA: But using any syncing service for Windows requires care & vigilance.

What more do you want to know?

Best,
Jim

3 Likes

This is really hard to answer for any service.

The services that we actively warn against, like Google Drive, engage in behaviors that actively threaten the integrity of a project.

But for a service like OneDrive that clears that bar, it all comes down to user-specific factors. How reliable is your internet connection? How big and how complex is the project? What are your work habits: how much time do you usually allow when switching between platforms? How many different devices do you use? How likely are you to pay attention to error messages, and how confident are you in your ability to resolve them?

3 Likes

Since there was recently a long and contentious thread on exactly this topic, I feel like I should clarify.

Scrivener does not directly interact with any synchronization service on any platform, with the sole exception of Dropbox for iOS Scrivener. By that definition, we do not “support” any Mac or Windows synchronization service.

We do offer discussions of best practices and possible issues whenever we feel it’s appropriate. The relevant part of our Knowledge Base is here:
https://scrivener.tenderapp.com/help/kb/cloud-syncing
For any service, though, the vendor is the ultimate authority on what the service is and is not capable of. We are not Dropbox/One Drive/iCloud support.

We encourage users to do their own due diligence, recognizing that no one else will care about their data as much as they do. In particular, never rely on any synchronization service – including Dropbox – as your sole backup for critical data.

3 Likes

That is really helpful!
Can someone tell me why LL does not allow me to install Scrivener in 2 locations (my PC and my laptop). It gave me this long message about “its not running from its originally installed location” blah blah. Help,

You absolutely can install Scrivener on multiple devices. Many people do. This warning has nothing to do with that.

This message was just a warning, correct? It should still let you use Scrivener. It’s annoying, but you can ignore it.

At one point I was also regularly receiving the same warning, and then I changed something about my configuration and it stopped happening. I’m sorry, but I have no recollection what it was that I did to make it go away. :exploding_head:

Maybe someone else will know.

Best,
Jim

You would be hard pressed to hit the 2GB Dropbox cap for their free account unless you are dropping photos and videos into your projects. A novel could easily take up less than 30mb.

I also didn’t want to use Dropbox as I like Google. I also find it frustrating that Scrivener only really supports Dropbox. But, it works, it’s stable, and secure. I then use Google and iDrive to automatically store my short and long-term backups, respectively. This gives me the additional benefit of having redundancy across multiple platforms.

My advice would be to follow Scrivener’s recommendation and stick with Dropbox to avoid known issues with other cloud-based providers.

2 Likes

I appreciate the input, but would like to know what the ‘known issues’ are with other platforms.

My “hypervigilant” approach to hosting Scrivener projects in the cloud works like this:

  1. I set up Scrivener to make date-named ZIP backups whenever I exit a project.

  2. I host those backups on Dropbox in a folder called “Scrivener Projects”, with lots of README notes saying “These are the original project files. They are not backups.” This Scrivener Projects folder on Dropbox is where Scrivener has been set to save all backups. Note that ALL instances of Scrivener on all my computers save directly to this Dropbox folder. Note also that I never use Scrivener on two computers at once.

  3. When I want to work on a project, I copy the most recent dated backup ZIP file from Dropbox onto my local computer and edit that copy. This means all editing is done on local files, not on Dropbox. When I close the project, Scrivener makes a dated backup in the Dropbox folder. Thus, every work session creates another backup ZIP on Dropbox.

  4. For safety, I also copy the ZIP on Dropbox to a local backup drive. This is the “actual” backup. The one on Dropbox is the “official original file” (even though the name contains “.bak”).

  5. Finally, since step 4 confirmed that the latest backup ZIP is in the Dropbox folder, I delete the project folder I just worked on (from my computer). This is important, because it prevents me from editing it at a later date, when it might have become out of date (due to editing on a different computer).

Note that this whole scheme is designed for use by one person; it wouldn’t be appropriate for shared projects.

To simplify this workflow, I use a keyboard macro that copies the Dropbox ZIP to a local “Scrivener Editing Buffer” folder, un-ZIPs it, selects the .scriv file, and opens Scrivener.

There are various ways to automate this workflow. I use Directory Opus, a wonderful file explorer program with powerful macro capabilities, but AutoHotKey would be a viable alternative. It might even be feasible for L&L to build comparable functionality into Scrivener, if it’s not too far out of scope.

This approach would likely work just as well on OneDrive or Google Drive, or even on an accessible NAS drive.

I hope this helps someone. Cloud-hosting is increasingly essential for a lot of workflows.

Cheers,
Allen

1 Like

You can find this information by searching the knowledge base and this forum where you will find lots of posts discussing this. In short, if the product advises you not to use a platform, if you do, you accept responsibility if your document becomes corrupted. Have a process in place for backups that will protect you from this decision in the event you lose work. Good luck!

2 Likes

I used Dropbox for years without problem; I still have it but because it has been blocked in China since about 2010—where I was then and where my collaborators are—I had to move on. I moved to the late-lamented Cubby, which actually had advantages over Dropbox, but which went to the wall in 2016. Since then I have used Sync.com for my Scrivener projects and some few other things.

Sync.com themselves claim it is not suitable for Scrivener type projects. However, in all these years, the only problems we have run into have been from being to hasty in shutting down the computer before the project was fully sync’ed or before the user.lock file had been deleted from the server. In that it is no different from any of the others, though my impression is that it might be a tad slower than Dropbox. On the other hand, a free account is 5GB rather than 2GB, and I believe it has a higher level of security with data being encrypted during transmission—hence the slight slowness, perhaps. Like Dropbox—on the Mac at least—but unlike iCloud, there is a menu-bar icon which shows whether it is fully synchronised or not.

I have iCloud, but, although it can be used, I don’t use it for Scrivener projects mostly because of lack of transparency over synchronisation status. I use it for many other things, however. I also have Box, which claimed a couple of years ago to be Scrivener compatible, but I’ve not tried—it’s not available in China.

I know nothing about OneDrive, but there are a number of threads on it.

Google is known to screw up live Scrivener projects so should only be used with
zipped backups.

My ½p.

Mark

2 Likes

In my case, I have the source file on Dropbox because I access it across devices. As a result, I make sure I do not save my backups to Dropbox as I don’t want them on the same platform. My backups go to Google via Google sync feature, the oldest being moved to Google Trash for 30 days before deletion. So, this gives me 30 days of backup. I then use a free iDrive account to also send backups to that service. While I do that at a high frequency, I don’t really need to do it more than once a month as I already have Google protecting me for the first 30 days. But, I currently have a higher frequency so I have redundancy of backups across two platforms. I will probably move this to once a week at some point. I check to ensure this automated backup system is working every day. I didn’t want to have Dropbox in my workflow but Scrivener wants me to and now that I do, I am thankful as it’s working well and I like having my source file I work on on a different platform than my backups.

1 Like

I agree that multiple locations are absolutely essential for good backup! It sounds like we’re doing roughly the same thing, except for editing. I consider the backup files on Dropbox to be the source, and I always edit locally. And I also back them up locally.

The reason I edit locally is that on one or two occasions, using a project on Dropbox, I was editing a large project very fast, making large changes (which required longer transfer times to Dropbox), and while working in realtime I got out of sync with Dropbox. Some component files got corrupted, and data was lost. I recovered all of it from a very recent backup, but this convinced me that local editing was safer.

This was provided upthread by @kewms, where she linked to the advisory posts in the L&L Knowledge Base.

1 Like

Local editing is definitely safer. A service can’t damage data that it doesn’t have.

The only real downside to this approach is housekeeping. You’re responsible for keeping track of which version is which.

It’s also a bit less convenient if there’s an iDevice involved, due to the relative clumsiness of transferring data to/from iOS.

1 Like

I totally agree with you. If the Scrivener iOS app didn’t require Dropbox for the source file I would absolutely always keep it local. That said, it’s been working very well.