Keeping project on SD card

Is this a simple way to by-pass the sync process?

I have the latest version of Scrivener on my desktop and my laptop. I would like to work on my major project on either machine (but not simultaneously). Instead of using sync folders or Dropbox, can I not place the project (the entire project.scriv folder) on an SDHC memory card and then just insert the card on whichever computer I want to work on?

I would of course keep backups at a third location. And would be sure to always close the project first, before I move it to the other computer. No one but me works on this project and no one else has access to either computer.

This seems like such a simple procedure that I wonder if there is some hidden problem with it. Is there? Are there any obvious drawbacks? Ive tried it out with a small throw-away project and it seems to work, but I haven’t yet dared to put a real project on the card.
TIA for any assurances–or warnings.


Sure. An SD card is just another form of removable drive. There are a few things to consider, though:

  • Be aware that links to files stored outside the project will break if the path to the outside resource changes.

  • SD cards are not very fast relative to the local drive on your computer. We recommend copying the project to the local drive, then copying the edited project back to the card when you’re done.

  • I would also recommend having each instance of Scrivener make its automatic backups to the local disk. That way no single disaster is likely to wipe out both the card and the backups.


Thank you, Katherine, you’ve made my day.

My outside-the-project links are all in my head, so that’s not a problem. And I intend to back up not only on each local drive but an a third location as well, a USB stick or an external hard drive.

Regarding speed, I have an SDHC card rated at 85MB/s. Assuming that rating is accurate, is that significantly less than the local disk speed might be? I suppose I could try it out and if I notice any slowdown I can then go to the method you suggest.

Appreciate your help.


Do not expect to get that. Your HDD or SSD interface is normally rated at 600 mb/s. Don’t expect to get that either. A recent review of the burst rate available on an SSD explained that after the high burst, the speed would drop to only 300 MB/s.

I would be afraid of using the SSD.

  1. it is slow
  2. It is less reliable
    Since Scrivener uses a “We’ll take care of saving so you don’t need to think about it strategy”, I’d be concerned if you greatly multiply the time it should take to save. If you follow this not-recommended strategy, then watch the * after the name of the file at top. It appears when there are unsaved edits and disappears when they are saved (a few seconds of inactivity).

Another approach if you don’t want to copy to the internal drives each time, is if you were to buy an external SSD usb 3 drive and used that, then I would expect it would come much closer to the local drive speed.

Thanks for clarifying the speed issue, Steve.

I’ve experimented with that small unimportant project and the asterisk doesn’t seem to hang around any longeer than it does when I’m saving to local disk. But perhaps it would be different with a bigger project, so I’ll have to keep a close eye on that.

But I’ve had another idea and I hope you’ll warn me again of any downside. Instead of performing two copy/replace exercises everytime I switch between computers (to and from the SD disk), why can’t I bypass the SD disk entirely and just move or copy the whole project from one computer to the other, using my LAN. The laptop connection is wireless, so I know that will make it slow, but I can’t imagine it taking more than a few minutes. My normal zip backup of the project to a USB 2 flashdrive takes less than a minute.

Again, TIA for any help.

Sure. Same fundamental issues as an SD card, really. Plus the potential for connectivity failure, particularly with the laptop.

The mistake I would be sure to make would be to forget to update the laptop copy before taking the laptop off to another location. Don’t be me.

OTOH, there’s no fundamental reason why the server couldn’t be accessible from off-site via the internet. (Security for such a server is entirely at your own risk, of course.) That would allow you to update whenever you want, but would also re-introduce all of the lost connectivity/synchronization issues that you run into with something like Dropbox.


Be sure you’re clear on the difference between saving and copying the project.

If you save what you’re working on to the local disk, Scrivener only needs to save the files that have changed. That might only be one or two text files, so the time required will be trivial.

If you copy the project from one disk to another, Scrivener has to duplicate the whole thing. This can take substantially more time, especially for large projects, and especially if you have a relatively slow connection to the destination disk.

(This is also why backups take longer. A backup is a full copy of the project.)


Using the LAN is the best choice for keeping two machines up to date if you wish to keep it all on your own equipment (as opposed to using the Internet like Dropbox). This is my preferred mechanism for working between machines on the same network. I’ll resort to external drives for only very large transfers.

Best approach: use the File/Back Up/Back Up To… menu command to:

  1. Select the shared drive directly as a save location.
  2. ZIP the project you are sending.

The first part is just a matter of convenience. You don’t have to first create the copy and then transfer the copy with your file system—when the process concludes you’ll have everything you need on the second machine. Plus by default you get a datestamp on the .zip file which greatly minimises confusion over which is latest.

The second part makes network transfer times go from agonisingly slow to very fast (especially if you have a good network). The main thing that slows down a transfer (especially if you’re on WiFi vs ethernet) is lots of little files being sent one at a time. Zip means one single file gets sent in one long transfer.

Another approach is some sort of multi-machine synchronisation tool. I can’t recommend anything for Windows, but on a Mac I’ve used Chronosync—I can hook two computers together using any means for doing so and then punch a button to bring them both to parity in the areas I choose to do so. I’ve also used a third source, an external drive with the same sort of software keeping all three in parity. That works better when there is a second machine at a remote location.

I was just going to post same suggestion as Ioa!

Passing zipped backups between PCs is how I used to do it.

Much faster and more foolproof, as compared to manually moving live project folders & files over wire/wireless/ext storage.

(I’ve since moved on to DropBox syncing.)

Many thanks to all of you for chiming in.

The consensus seems to indicate that the best method would be zip backups of the entire project directly from machine to machine. I like that idea because it guarantees that even if there is some connectivity disaster during a transfer, the latest complete project will not be affected.

I’m going to try it right now with a small expendable project and will come back–to report success or for more help.

The zipped backup transfer is working fine. I’ve gone back and forth several times with a small project, with no problems. I still have to establish a personal protocol to make sure I extract the files from zip to the right place, and to assure that I’m workinig on the right version. And to ensure the real backups are in place. Otherwise, I can foresee possible problems.

So again, thanks to all.

I’d recommend using a good naming convention for the backups – something like Project_31May_1400 – to help you keep track of which is which.