Using Scrivener with Cloud-Sync Services
Our support thread on Working off of network drives has understandably left many users concerned about using Scrivener with Dropbox. However, the problems with storing .scriv projects on Dropbox have been somewhat overstated, mainly because we want to ensure users know that no syncing method is 100% safe. So, here are some guidelines on using Scrivener with Dropbox that should keep you out of trouble.
In theory, the following guidelines should be applicable to similar services, such as SugarSync, SpiderOak and others that work off the principle of automatically syncing an actual folder on your computer to a server as changes are made to your machine. This article will use the word "Dropbox" when referring to the sync service for simplicity.
IMPORTANT: If you are using either Google Drive or Microsoft's OneDrive/SkyDrive service, there are special considerations, which you can read about at the links below:
If you want to access a project on more than one computer, the most straightforward way is to use Dropbox, storing your .scriv file in your Dropbox folder. The project will then be available on any computer you have set up to sync to your Dropbox folder, and because a Dropbox folder is no different to any other folder on your computer, other than for the fact that it automatically syncs to your Dropbox account, you can open your .scriv project directly from there on whatever computer you are using, across all major platforms.
However, if you do this, there are several things you need to make sure of - if you don’t follow these guidelines, you could run into problems with projects getting corrupted or files not showing up correctly:
- Never, ever open the same project on more than
one computer at a time: be sure to close your project on
one computer before leaving that computer and trying to open it on
another machine. The good news is that if you forget, when you go
to open it on your other computer, Scrivener will warn you that it
thinks the project is open on another machine. Always heed this
warning. It is possible that you will see this warning when
the project isn’t open on another machine - for instance, if
Scrivener crashed the last time it was used or wasn’t closed
properly, or if the project was copied while it was open - but
always read read the warning and double-check. Only proceed with
opening the project if you are sure it is not open on another
machine. If you’re not sure, Scrivener gives you the option
of making a copy of the project to work on instead.
- Do not open the project before your Dropbox folder is
fully synced.: if you try to open the project while your
Dropbox folder is still syncing, you could be opening it in its old
state before it has downloaded the changes made from your other
computer - and by opening the project, you will overwrite those
changes with the older version you have opened. So be sure the tick
in the green circle is present in the Dropbox icon in your menu bar
- if it’s not, don’t open the project: wait until
Dropbox is fully synced.
- Do not shut down or sleep your computer before Dropbox
finishes uploading: the flip-side of the above is also
important. When closing Scrivener for the day, there will very
likely be a number of final files that Scrivener saves, and Dropbox
will need to load. If you simply sleep your machine, or let
Scrivener close as part of the OS shutdown sequence, Dropbox might
not get a chance to fully upload the final changes, and that means
the project on the server (and ultimately all of your other
computers) will be incomplete until you restart that
- Turn on automatic backups: (in
Scrivener’s “Backup” preferences tab on the Mac,
Tools > Optionsunder the "Backups" tab on Windows), setting Scrivener to back up your project on open or close (or both), preferably with the “Compress automatic backups as zip files” option ticked. Choose a backup path somewhere on your local hard drive. By default, Scrivener will use a location on your local drive, so in most cases you won't need to change anything here. This will ensure that your project has backups on every machine you use it on, as well as the “live” version in the Dropbox folder, so that even if the worst happens and the project gets corrupted somehow, you will have a recent version to return to.
- Reduce auto-save frequency: this step is
optional unless you are working on a very slow connection, such as
dial-up. Editing a Scrivener project can generate a lot of network
traffic because of how often Scrivener saves files to the disk.
With modern high-speed connections, this should pose no problem,
but with slower or unreliable connections to the Internet,
it’s a good idea to set Auto-Save (in General preferences) a
little higher so that changes are sent in larger batches to the
Dropbox server, rather than trickling in constantly. When working
this way, you might want to save manually more often, with the
File > Savemenu command. Alternatively, pause Dropbox: the newer versions of Dropbox allow you to pause syncing. This can be done from the status icon as all other functions with Dropbox can be accessed. Pausing syncing means that all changes made to the Dropbox folder will not be immediately synced to the server. Thus there is no need to mess with changing the auto-save frequency, and it keeps your entire working session in one "version" within the Dropbox system. Of course, you will need to remember to resume syncing prior to shutting down the system.
Follow the above guidelines and you should be good to work on your projects directly from Dropbox.
Caveat: Although these guidelines should keep you out of trouble, no syncing solution is 100% reliable, and every computer and piece of software is fallible. We can take no responsibility for work lost through syncing problems (or for any other reason, for that matter - always be sure to back up!).
Indications that synchronisation has damaged a project are when it fails to load properly, or if certain parts of the project go missing or appear out of date. If you leave your projects in a live sync area, and notice these issues, close the project and attempt to diagnose the problem on the disk. For Mac users, you will need to right-click on a project and select "Show Package Contents" to do so. The user manual contains an appendix, "Project Bundle Format", which documents the various folders and pieces which are of importance to a project, and what they do. You are advised to consult this if you come up against any files you do not know the purpose of. The key thing to look for are files which have had a parenthetical statement added to their names, which will state something to the effect of the file being conflicted, containing the name of the device that produced the conflicted copy, and potentially the date and time of the conflict. Most synchronisation services do this when a file has been edited on more than one computer and it cannot automatically determine which is best.
Advanced Tip: An easy way to find which .scrivx file is the best is to duplicate the project enough times to try each one separately at once. You can then load these different projects side by side and compare their Binder outlines to find the most recent one---and maybe to merge pieces together that got forked along the way. You can merge things into one project with simple drag and drop between Binders. Once you've decided which is best, make note of which duplicate it came from to use as your base for fixing further conflicts. You can probably discard the other duplicates at this point, as you wouldn't really need them for anything and keeping them around would only make things confusing.
There is often no "best answer" here, short of opening the files, examining their contents and figuring out which one is actually the best copy. You are not advised to manually modify the contents of any of these files. If the changes are interleaved between two copies, then move the conflicted one out of the project folder and use copy and paste to bring the correct passages into the open Scrivener project once you've reached the point where it can be opened correctly again. Some files might prove difficult to determine the best version of. The ".scrivx" file for instance contains the structure of your project, what you see in the Binder, as well as some other information. In these cases you may have to experiment, trying one file and then another to see which is best.
Naturally, you will want to make sure and set aside the damaged project before you start all of this, as a backup, in case the changes make things worse. It's also advised to do all of this offline. Either move the project out of the sync area or temporarily pause the software.
Your goal is to remove all of the conflicted duplicates, renaming them to their root names if necessary.
A much less "risky" method for sharing the latest version of your project between multiple computers using a synchronisation service is to essentially invert the above advice. Using this method, one would set Scrivener to automatically back up directly to the synced area of your computer. This means that whenever you close out a session on one machine, Scrivener would automatically create a backup for you, storing it in the synced location, and Dropbox will then upload that backup to every machine attached to your account. When you transition to the next computer, you can simply copy the latest backup off of the "stack" and use that as your local copy. To minimise confusion, we recommend the following guidelines:
- Set your backup settings to Dropbox: as this
folder can grow to be rather large, I recommend creating a new
sub-folder just for your Scrivener backups in the Dropbox area.
Unless you have a strong reason not to, using the .zip compression
option is highly recommending. Not only will it increase upload and
download speeds, transmitting one single file will always be safer
than transferring dozens, hundreds, or even thousands of files. Use
whatever backup frequency options you prefer, keeping in mind that
the backup should trigger somehow when you are done working on the
machine. Backing up when closing the project is usually a good
option to leave on for this workflow. You will need to do this for
- Be aware of sync status when switching
computers: the same advice from above follows here, though
the matter will be simpler if you use .zip files for backups.
Always be sure that Dropbox is completely done uploading before you
shut down the computer, and on the other side, make sure it is done
downloading before copying the latest project out of the backup
folder on the next machine.
- Use modification dates instead of filenames:
the filename of the project backup will be serialised, and thus a
safe assumption that the highest number is the latest is fairly
safe. Despite, it is a good idea to browse the folder with
modification dates visible so you can double-check that and make
sure the project backup you are copying is absolutely the latest.
It will also help you catch those times when you check too quickly
and Dropbox hasn't yet downloaded the last copy.
- Don't move the backup out of the dropbox folder or work on it in place: if you work on an un-zipped backup right in the Dropbox folder, then you might as well just be using the first method. Always copy the project out of the Dropbox folder, preferably removing the old .scriv project first to reduce confusion. So for example if you work out of your Documents folder, you would delete the old copy of the project first, and then copy down the latest one to start working on it. It is safe to rename the project folder (or file, on a Mac) to remove any backup naming conventions. If you using zipped backups, on Windows you can just double-click on the .zip file right in the backup folder, and then drag the project out of the ZIP window to your working area. On the Mac, you will need to copy (drag and drop with the Option key held down) the .zip file to the working area first, double-click to extract the .scriv project, and then you can safely remove the copied .zip. If you extract first it will do so in the Dropbox folder, causing a lot of unnecessary network activity.
The workflow described in step four will ensure that you only ever have one working copy of the project on your drive at once. This reduces confusion over which copy is the latest and keeps your working area clean. It also ensures that the integrity of your backup folder is not damaged. If you move projects out of it and start working on them, then they are no longer backups. So always copy. While this method is slightly more complicated and less transparent than the first method, it is orders of magnitude safer, because you only ever open .scriv projects outside of any external mediation. It also has the side-effect of placing your central backup location "in the cloud". That means even if you lose all of your computers, you'll still have at least one copy of your important work backed up to a network server. And naturally, losing all of your computers at once would be an unlikely scenario, so even just having your backups distributed amongst all of your computers (and any extra backup systems they use like the ones provided by your OS) will mean maximum safety with very little mental overhead.
External folder sync is intended for working on files in other programs and then being able to sync them back to Scrivener. You should never try to use external folder sync to synchronise Scrivener projects between machines - if you do so, you will corrupt your project and see some very odd results.
If you have any further questions, or would like to read and share tips with other users, please visit this thread.