The method that Textilus uses is designed to work more closely with the Mac synchronised folder feature. This feature lets you select items in the binder to export to a folder as files, and then the software monitors that folder for changes. Hence you can put the folder on a sharing network like Dropbox and edit the files from your phone.
So the reasonable analogue to this on Windows would be to use File/Export/Files... to create a folder of selected binder material, put this on Dropbox, and then copy and paste the contents of the modified files back into Scrivener, when you return to your computer. When I did something similar (prior to the Mac version acquiring this feature), I would make a new document and call it “END HERE”. Then I would include that in the export (and move it to the trash shortly after). The purpose of this empty document is to set a “last file edited” timestamp, so when I sort by modified in the file browser it’s obvious where I can stop copy and paste. All files changed after the export will be newer than “END HERE”.
Last note: never try to access the .scriv project folder via any third-party editors. The open project format design is there to make recovery reasonable in a worst case scenario, not to invite modification.
So, yes. It is a matter of the principle of how these things work, not a matter of the precise implementation. If Product X is taking pieces of your project and sending them to other computers you own, and any of those computers have the ability to disconnect from Product X, then it is trivially easy to end up with two different versions of a thing that must be manually merged when all devices are once again connected.
Recently I purchased an old PowerBook for writing on when I’m out and about, so I can leave my expensive and heavy 17in MacBook Pro at home.
The last time I used Scrivener with the PowerBook, I saved the project I was working on, waited for Dropbox to finish its sync, before closing it.
When I got home, when I checked the Scrivener file it was corrupt and wouldn’t open - it’s binder was damaged. And neither would its backup. And the previous backup file was from the previous day – although I’d been working on the project for hours during that day.
I’ve been unable to recover the data from the corrupted file, as all versions of it were corrupt: on the PB, my MBP and on Dropbox’s server – as well as its backup file.
If this occurs again, is there any way to recover files I created within Scrivener from with the project file?
I have been successfully using Scrivener with Dropbox for several months, opening the project on Windows and Mac (not at the same time obviously). Starting earlier this week, I am suddenly having a problem where I open the project on my Mac, and any new files I created while on Windows are put in “_recovered files” underneath the trash. And it seems like any files I deleted on Windows are still there, undeleted. This has happened twice despite meticulous closing, backing up, and waiting for dropbox to sync.
Anyone else having this problem? (Any text changes I make to the files, incidentally, are preserved, it’s just something about putting them where they should go…)
I just wrote up a procedure for recovering projects damaged due to synchronization conflicts and thought I’d post it here. This procedure is not guaranteed to work, but it is guaranteed not to make matters worse, assuming that you follow the instructions and create a backup before you start.
These instructions assume that you are on a Mac, and that the Dropbox project is shared with at least one co-author. If you can’t figure out how to modify them for other situations, you probably shouldn’t be rooting around in your project file anyway.
In case of Dropbox synchronization conflicts, please do the following:
In Scrivener, use the File -> Backup -> Backup To command to make a backup of the project to a convenient location. What you are about to do is potentially destructive; this backup gets you back to where you are if needed.
Copy the project to an area that Dropbox can’t access. Ask your co-author to do the same, as what we are about to do will ultimately overwrite the Dropbox copy. Your life will also be easier if your co-author suspends work on the project while you’re working through these steps.
(While they are waiting, have them read the Knowledge Base article linked above, on best practices for working with Dropbox.)
In Finder, right-click on the project folder (ends in .scriv) and select the option to Show Package Contents.
When Dropbox finds a file conflict, it creates a new copy of the file with a name like “Filename[Conflicted copy]” If you see any such files in this top level folder, drag them out to your Desktop or some other convenient location. Do the same with any Recovered Files that you find.
Do the same with the Files folder and its subfolders.
Close the Finder window. Open the project in Scrivener.
Using Scrivener’s File -> Import -> Files feature, import all the conflicted files into a separate area of the Binder. Inspect them one by one to see if there’s any material you want to keep. Move the ones you don’t want to keep to the Trash, and empty the trash.
Create another backup. Close Scrivener.
You now have a known good copy of the project. Delete all copies from Dropbox, first making sure that your co-author actually created a local backup when you asked them to up above. Allow Dropbox to synchronize to make sure these copies are really gone.
Drag the known good copy back into Dropbox, and allow it to synchronize.
Ask your co-author to inspect the new Dropbox copy to make sure all of their work is in it. Anything missing should be found in the local copy that they created before, and they can simply drag it from one copy to the next. Don’t do any further work yourself until they tell you everything is okay. While you’re waiting, read the Knowledge Base article I linked up above.
Allow Dropbox to synchronize any changes that your co-author made.
You should now be back on track, with identical good copies of the project on both systems. The best practices in the article I mentioned will help you stay that way.
So sorry if I’m being dense on one of the most basic of issues here, but I am trying to set up synching with Plain Text. I need to enter the location of Dropbox folder to which I want to synch - but I cannot find a way to enter that url in the dialog box in Scrivener where it asks for the location of the shared folder; it seems I can only navigate to a folder on my hard drive.
I must be missing something terribly simple. I’m using Mac OSX Mountain Lion, if that matters.
As a Scrivener newb but a Mac computer veteran - it seems to me that using the Dropbox folder on our computer as the repository for the working scrivener files is NOT a good idea because it can trigger syncing errors and cause corruption.
It seems to me (and please correct me someone if I am way off line) that the best strategy is to keep ALL of the scrivener files, including it’s backup files, on the main hard drive.
Then, after a session or a break in a long writing session, go to the main Scrivener folder for that project and copy it across to a suitable folder within the Dropbox folder. Giving it a new name starting with the year, then month, then day, then version. Such as “2013-08-05.1”. It will then start to sync with Dropbox safely. At the end of the session for the day, do the same thing and rename it “2013-08-05.2”.
If you’d had the chance to read the entirety of advice on this over several years, you’d have seen that opinion has moved from recommending keeping zipped back-ups in your Dropbox folder and your “live” package elsewhere on your hard disk, to the possibility of keeping your live Scrivener folder there and your zipped back-ups elsewhere. (N.B. I’m talking about using Dropbox to enable you or others to work with one Scrivener package on different computers - not “External Folder Sync”.)
I know of a number of people who have followed the live-Scriv-package-in-the-Dropbox-folder course without a problem.
On the other hand, saoir, you’re recommending a more cautious plan than either of these.
I guess the message is that sync-ing via Dropbox, or indeed any other cloud device, is not entirely risk-free - to a variable extent, depending on the route you choose to use, and the care with which you use it. Ultimately, whichever recommendation you accept it seems to me depends upon a number of factors - one of which is the value to you of your work.
For writing that may earn me income - and being an innately cautious fellow, but lazy with it - I follow the advice to keep zipped back-ups in my Dropbox folder.
If I didn’t occasionally access my projects from another computer, I’d probably not keep the live projects out of the Dropbox folder, but I would absolutely continue to keep my zip-compressed backups in the folder. Since that folder is also on my hard drive, it gets backed up hourly by my local backup solution (Time Machine… a built-in Mac backup process), and also to my off-site backup drive when I take my laptop to work–at which time, all of my backups are in four places (local hard drive, dropbox servers, home backup drive, office backup drive).
If you don’t have at least one backup solution that is in a separate physical place from either your main drive or another backup, then you’re putting your data at terrible risk, so I would strongly urge you to reconsider your stance on only manually copying your backups to the DB folder.
One other note; you can recover deleted DB files if you know where they were previously.
Hi Robert - not sure if your comment refers to my post above, but if it does, yes, I have Time Machine backing up versions to an external hard disk once an hour, Super-Duper cloning to an external hard disk once a day and Dropbox syncing to a Windows computer whenever it’s opened. I circulate the external hard disks to my son’s home roughly once a month.
I don’t regard Dropbox itself as a back-up, more a conduit, but maybe that’s just prejudice.
The post was more for Sair (who asked for opinions), but I do think of DB as a backup. Really, any duplicate copy is a backup. Any co-located copy is superior to any duplicate copy that can be destroyed in the same localized event (fire, theft, superhero fight). While dropbox isn’t a robust backup solution, it does allow for recovery of deleted files (differential backups), and is a co-location solution that doesn’t require you to take any conscious actions.
Leaving scrivener backups outside a Dropbox folder (or similar “cloud” solution) just leaves me scratching my head though. I could understand not wanting sensitive data stored where some people (NSA contractors, for instance) can easily get to it, but since it doesn’t interfere with your other backup solutions, and adds co-location within seconds of the backup creation, I don’t see a reason to avoid it from a data protection perspective.
Hi Hugh - I didn’t read the full history because what matters is what is best now … not in the past. But I get where you are coming from.
My logic comes from the assumption that almost anyone using Scrivener must be working on something valuable. Hence any loss is something to be avoided if at all possible. By only moving backups into Dropbox at the end of sessions, that minimises the time period during which errors can occur. If the WIP files are being constantly updated AND sync in a constant back and forth process … then it follows that the window for errors is enormously expanded.
I know of a number of people who have never had a hard disk crash … but I wouldn’t recommend everyone to abandon backups
One of the challenges of risk management is that you can become overly focused on one set of risks, and thereby become blind to others.
It’s true that only moving backups to Dropbox at the end of a session reduces the window for synchronization errors. However, it increases the window during which the work only exists in one place, on the local hard drive. Dropbox users in particular tend to be mobile users, and therefore possibly more vulnerable than stationary users to risks like theft or physical damage to the machine. It’s a tradeoff that each person must evaluate for themselves.
I would definitely encourage Dropbox users to read the protocols elsewhere in this thread in order to get a sense of what the risks actually are, how to avoid them, and how to fix any problems that arise. Most of the problems I see in the support queue are avoidable user mistakes, not failures of Dropbox, Scrivener, or the synchronization process. Moreover, most synchronization errors, while annoying, are not actually fatal. Usually any missing data is still stored somewhere, it just takes a bit of digging to find it.
FWIW, I only put projects in Dropbox when I plan to work on them remotely. I don’t use it as my main data store. I keep backups for Dropboxed projects locally, so the backup and the original aren’t both at risk if a problem occurs. (And, not counting Scrivener’s internal backups, I also have three different non-Dropbox backup mechanisms.) I’ve had exactly one synchronization error: when the cable went out and my internet connection dropped in the middle of a sync. Since I saw it happen and knew there was a problem, it was easy to fix: treat the local copy as canonical and don’t work on it remotely until the net comes back. (I could have transported it to my laptop via a thumb drive, but the outage didn’t last that long.)
So yes, some caution is required. But overall, I would say that the benefits of cloud accessibility and backup outweigh the risks of synch errors.
I’m going to poke at this issue one more time, and then let it rest…
Unless I’ve missed something about the Dropbox syncing process, there is zero risk to storing zipped backups on DB folders, since there’s nothing to sync (just to upload & distribute). It writes a zip archive to your hard drive and then that gets distributed to the DropBox servers and your other computers. New backups with date stamps in their names will never have a name collision, so no sync issues there. Can you come up with a sync collision scenario with Scrivener backups? I can’t. But I can come up with many real-world situations where the backups you haven’t manually copied are lost (theft, fire, HD crash…)
I cannot get a Scriv file to save to Dropbox. I cannot get a Scriv file to e-mail. When I try there is nothing in the file. Said file, when e-mailed, is about 1kb in size, so it clearly isn’t the project in full. What is the deal?
Well I think Katherine’s point there was that if you have Scrivener set up to use an online synchronisation service to distribute your backups, then you reduce your maximum distributed safety net (that being the sync service’s servers and all of your devices currently turned on and hooked into the network mirroring that data) to only those events wherein a new backup is created. For someone like me, that may mean several times per day, as I have automatic backups triggered by manual saving rather than closing (too often I open and close things without changing them, and thus I do not want to dilute and reduce my rolling backup list to non-essential events like quickly checking a fact in the project fifteen times in the past few months). For others that might be once per day when they shut down their computer. For others that might mean one a month of they don’t have their backups set up to accomodate their working style very well. Whatever the frequency, several times a day to rarely at all, there are still broad stretches of time wherein if your computer overheats and suffers a fatal breakdown, fire destroys your home, etc. during those larger blocks of time where you are sitting and writing, rather than sitting and telling the software to back things up, your protection is reduced to whatever is available at an off-site location the last time you bothered to upload a Zip.
The risk is that 99% of the time you aren’t making Zip files and uploading them (and if you are, perhaps a visit to the psychiatrist is in order), and thus you aren’t fully backed up everywhere. Having the project on the sync folder itself means, so long as you are wired up to the Internet, your project is 100% duplicated everywhere, nearly constantly.
And of course, that is where you can start running into problems with collisions at the data and networking level and so on. Working that way is inherently more risky than transferring a stack of uniquely named files periodically.
Personally, I don’t think the average person needs 100%, real-time backup transmission. Periodic transmission is good enough, so long as those periods are not too long (backing up off-site several times a day is fantastic, and a level of protection no normal consumer could ever aspire to until fairly recently), and even more so if one has a good level of local redundancy, like a Time Machine drive or other form of high-frequency automated delta based backup. But, it’s something to consider, especially if you’re working habits cause your periodic full backups to be rather sparsely arranged across time.
Your forum tag states you are on a Mac, where a Scrivener project appears to be a file (it is actually a folder with anywhere from dozens to thousands of files in it). This can make things confusing when using e-mail, because e-mail attachment protocols were never built with the eventuality of attaching 1,454 files in 82 folders, and then reproducing that elaborate structure on the recipient’s machine. Make sure to always use .zip compression to archive the project into single file before transferring it over the Internet. File/Back Up/Back Up To... is the best way to do that. Now, if you were a Windows user I would also question whether you considered the whole folder to be the project, or just the one “project.scrivx” file. The latter is not the whole project, but rather just the part you see in the Binder (and a little extra). So if you are using a PC, and you just sent a 1kb text file via e-mail—yeah, the rest of the project is in those folders. You should be dealing with the whole folder complex that “project.scrivx” file is nested within. That is the project. On a Mac, all of that is obscured from you, for the top-level folder itself masquerades as a file.
This is not a terribly uncommon thing on a Mac. In fact all of your software is folders with thousands of files in them, where the top level folder is made to look like a “file” that you can double-click on to launch, or put into the Dock as though it were one thing. So whenever you get a weird result like that where you attach what appears to be a file and it doesn’t work, try right-clicking on that file in Finder, and if you see a “Show Package Contents” contextual menu item, you know it’s actually folder you are looking at. It should be Zip compressed for transmission.
As for not being able to save to Dropbox, I’m afraid I don’t understand the question. Are you saying that you get an error when you try to save something to this particular folder? It’s probably a permissions issue then. There is nothing special about that folder from Scrivener’s “point of view”.
I have Dropbox, but I also have a gmail account and have started playing with Google Drive. I like Google drive because when my editor approves a chapter, I can just save it right to Google drive now from gmail - it’s a recent upgrade and it’s working really well if you have gmail. :0)
Just make sure to avoid using Google Drive for storing your live projects. We’ve noted a large percentage of failure reports from other users, where Drive seems to revert or even destroy data. It seems to work fine for storing exported files or zipped backups of Scrivener projects, however. My guess it that its underlying technology is not equipped to handle a high-bandwidth format like Scrivener’s.