This dialogue box appears now and then when I’m writing. I do have free space on my computer, although not terribly much, 9 GB, but I guess it should be enough. When it appears I click OK, and haven’t noticed that I’ve lost any work (touch wood). I save my project in Dropbox. Should I do something about it?
Looks like it’s trying to copy the files to their names tagged with .old on the end of the name. This is a common way to backup the prior save so you can get it back if you want to undo your work. This also sounds like you’ve got this Dropbox folder designated as your work folder, that holds your projects.
Couple of questions, then.
What’s your save frequency? Scrivener defaults to whenever there’s 2 seconds of inactivity. You can change this frequency in Options-> General->Saving.
Does this dialog box appear every time you pause? It doesn’t really sound like it; it sounds like it occurs every once in a while.
So Windows occasionally does stuff to your drive. Like index it. This can cause issues (which is why I disabled Windows indexing). Also, any updates it wants to download go on your drive. some of those are quite large. Some of Windows’ other functions use free drive space as temporary storage space.
9 GB might sound like enough, but Windows uses some of that, and doesn’t tell you. The recommendation by most drive manufacturers is to leave 15-20% of your drive empty, so you might want to move a good chunk of the drive’s content elsewhere and see if that helps. Cleaning up a hard drive often helps with its performance as well. If the drive is a 1 Terabyte drive, then 9 GB is less than 1% of its capacity; if it’s a 100GB drive, then it’s under 10% of its capacity.
So I’d suggest cleaning your drive of unneeded stuff, perhaps 20 GB worth, and see if this continues or stops. Mind you, if it’s a 1 TB drive, you likely want a 150-200 GB free space, but you can get by with less. But defragmenting it, if ever you do, will be very slow, and may not be possible if the free space is too small. Even for the newer SSD drives, their makers recommend a substantial portion be left as free space.
Thanks a lot for answering this! I will free up some space. I have a 256 GB SSD disc, but the C partition is only 95 GB (It was a mistake to make it so small), so well, I have about 10 percent free, but I probably need more.
I save every 2 seconds, and no, it doesn’t appear all the time.
So if understand right, do you think this is a thing Dropbox does to backup things? Or is it Scrivener?
Just to be safe, try increasing the interval from 2 seconds to 10. These are saves of whatever item(s) in your binder that have changed since the last time you paused for that period of time, which are then synchronized from your Dropbox folder if that’s where your “live” project is kept. I think it’s possible that if your connection to dropbox.com is slow enough, and you pause frequently while editing a document, a backlog of synchronizations could be the culprit, so increasing how long of a pause is required before automatic saves occur could help.
FYI: Dropbox is a synchronization service, not a backup, in the sense that if you’re connected to the internet, your old copies (a backup) of your files are replaced rather than being preserved so that you can get back to a previous state. If something bad happens to one copy, all copies that are synchronized by Dropbox will have that bad “something” done to them almost immediately. You can recover individual files back 30 days on the Dropbox website, but that doesn’t really work well for Scrivener projects, which are composed of potentially thousands of obscurely named files and folders. It’s not impossible, but it’s also not a trivially easy way to recover from inadvertent deletes.
Scrivener does have a built-in feature that creates backup copies every time you close (by default). Those settings are (globally) under File->Preferences->Backup, and if you want to override the location for an individual project, you can also go to Project->Settings->Backup. Those are copies of your project as they existed at a point in time, and are not replaced with your current edits. A certain number are preserved before the oldest copies are thrown out (so you don’t end up with an infinitely growing number of backups).
I wouldn’t recommend putting your scrivener backup copies on Dropbox (all your eggs, one basket…) but another sync service, or a real backup service/system that includes the Scrivener backups folder is a good idea.
Thank you! I do a lot of backups both to Dropbox and now and then to other locations. But it might be a good idea not have Dropbox as the primary location for backups. I’ll change savings to 10 seconds.
Another ding against keeping scrivener backups and your ‘live’ project in Dropbox, is that when you close your project, generating a backup file automatically, it can take quite a while for Dropbox to finish syncing. You won’t be able to tell if it’s just taking a while to copy your backup, or if it’s also waiting to do it’s final bit of tidying up after the backup has been uploaded to the cloud. That means if you want to move to another computer or iOS device to continue working on your project, you have to wait for everything to sync up.
Now and then I get this message, too. Or something like that. (I never rad through the whole thing, since this is tech gibberish for me.)
But it’s certainly not a question of disc space: My one is huge - 1 TB with lots of empty space.
I see it as a sort of hiccup, perhaps while syncing to the dropbox. I just click “save” again and then it works okay…
I’ve recently gotten a message , during the sync process, about a particular folder in the project failing to sync with an external folder (I sync to an external drive that is not synced to online storage). That indicates some issues with that drive, perhaps (may need to defragment, or perhaps simply zip it up and rewrite it). The project itself is correct (I checked), and on restarting that project, Scrivener asked me if I wanted to sync the working project files from the SYNC’ed files because they were differnt, and I answered no, because there was a problem with saving it, so whatever’s there is likely corrupt.
But it was not the message the OP got; not even close. If it happens again, I’ll take a screenshot and post it.
From the message box, it appears Scrivener is the program issuing the message.
With an SSD, I would DEFINITELY slow down the save frequency (by increasing the inactivity period, maybe higher than 15 seconds), because SSD’s have a limited number of write cycles before they cease to function. SSD’s also need extra space to handle internal swapping (a lot goes on behind the scenes when you save to an SSD).
Those are a few places this could come from. Free space is one.
This could also be a file use collision issue. That is, Scriv wants to save, but Dropbox is accessing the file, maybe locked it, and is preventing Scrivener from doing that.
There are ways of preventing Dropbox from syncing constantly, but they’re relatively involved (except for turning it off); I don’t know how much messing with it you want to do (scheduling synchronization means using Windows task scheduling). You might turn the service off for a while (an hour or more) while you’re working, and see if the messages stop. And then turn it back on, and see if the messages become more frequent.
What I would do, personally, is stop using Dropbox as primary storage. I created a folder, C:/WRI/, and that’s where my writing lives (it’s a short path to write, and easy to remember). So, C:/WRI/Project_x.scriv might be a project folder.
I sync some projects to an external folder (actually an external drive), something like H:/WRI/Project_x_sync/. That could just as easily be C:/Dropbox/project_x_sync/, if I still used Dropbox.
I’ve got Scrivener set to sync on exit, and to check contents on startup. I can force Scrivener to “Sync now” if I want (I never do, though).
You could instead set your backup to a Dropbox folder. That would mean the files would only change when you exit (or start, if you backup on startup, or on every manual save if you set that option), and those’d be the only times Dropbox would synchronize them. Back them up zipped, and they’ll use less space.
So, some options to check. I would definitely free some space on that drive, though; Windows is likely running into issues, too. It may not be the primary source of the problem, but I’d bet on it contributing.
Hi guys, we have mentioned MANY times, that working with your project located in Dropbox is not a great a idea. Most of the time it works, but sometimes there are glitches like these. Please, backup daily your project in Dropbox or even on every save or project close, but avoid working on your project while in Dropbox. Just point your automatic backup location to a Dropbox folder and you will have multiple backups to choose from later on in case something bad happens.
Scrivener is doing its best to preserve your data against crashes in the operating system and Scrivener upon saving. In Scrivener v3 we use an new algorithm, which is the default. In Scrivener v22.214.171.124 we have the old and the new algorithm, but the old v1 is still the default. The differences between the algorithms is explained best in the screenshot attached from v1. I cannot imagine that someone would like to switch to the old algorithm, just to be able to work in a Dropbox location, if he is aware that he is using an old saving algorithm which might lose his document upon a crash. Because of this we decided to use only the newer algorithm in v3, which might give you the above mentioned message sometimes.
I can give you many examples from the support queue about people who believed too much in their cloud sharing service, but resulted in projects beyond repair or unexplained project changes. It seems like it works in 99.9% of the cases, but when the 0.1% strikes, it hurts, especially if you have not done a backup. For most of you writing your project in Dropbox is a backup, which indeed is not. Multiple services(Scrivener and the Cloud service) using the same database(your project) is something asking for unexpected source of trouble.
If your Scrivener project is important to you, backing it up, should be as important too.
Ok, so what you are saying is that syncing the project through Dropbox is less safe now than in 1.9? There I have done it for many years without problem (or, rather without problem as long as I was careful to let Dropox sync before opening the project… learned that the hard way). It seems to be working as fine in v3. (well except for what this thread is about, but as far as I can see there is no harm done to the project and changes are saved)
I really need to work on two different windows computers. If Dropbox is not recommended, is there another way of doing this without complicating it too much?
And yes, I do back up, both on opening and closing, and manual save…
Writing inside a Dropbox location has not been recommended before and is not recommended now. Writing in a Dropbox location while Dropbox sync is active could cause data loss in the past and can cause data loss now. The old saving algorithm could cause data loss on Scrivener or OS crash, the new one handles this better but is more unfriendly to cloud syncing services as it involves more file operations, which can trick the cloud sharing services. For us the new algorithm is better as it will always preserve the last valid version of your document and less likely to wipe a full document. Just because you have not had an issue constantly writing in Dropbox for years, does not mean that you have an insurance against not having troubles tomorrow.
I would recommend to sync with Dropbox before your writing session. Turn off Dropbox, while you write, and sync the whole project back to Dropbox at the end of your writing session. This will sync your changes at once at the end and not while you write and save continuously in Scrivener. Still, this approach is asking for troubles, if for some reason you forget to sync with Dropbox before your writing session and sync only at the end of your writing session. I have no idea which file versions will be synced where and how. We have done a tremendous amount of effort dealing with this in Mobile syncing, but this is not available from Dropbox and very bad things can happen.
ADDED: Recommended Dropbox usage with backups: If you create automatic backups in a predefined Dropbox location upon project close, or manual save, you can have Dropbox running and syncing safely in the background. Once you go to the new computer, copy your latest project archive to your other computer. Extract its contents outside of Dropbox and start writing. Keep automatic backups at the same location while you write on your other computer. This takes an extra moment to copy/paste/extract your latest version of the project on the new computer but is the safest and bullet proof syncing with Dropbox that I can think of.
To close the topic: The message that you see in other words means “Scrivener could not save your document changes at the moment, due to Dropbox which has locked some files. Try again later, hopefully it will succeed.”, Still, if this happens upon closing your Scrivener project, it will be unpleasant.
This seems to be new information and is not in sync (heh, I kill myself) with the general guidance on using Mac or Windows Scrivener with iOS, where it is assumed the active project is in the Dropbox folder on the PC or Mac and the Dropbox client is running.
If this is going to be an issue for the Windows version going forward, that decreases the usefulness and the reputation of Scrivener for Windows. Given the amount of bile over DropBox being the only officially supported sync engine for the iOS version…this is not a good look.
If this is indeed the new state of things going forward, then I feel that you need to provide the option in Scrivener (off by default, warned about very strongly if Scrivener detects DropBox is being used) to integrate with the DropBox client and turn the DropBox syncing on and off in coordination with Scrivener save activity.
This is potentially enough of an issue that it would keep me from purchasing a 3.x license and confining myself solely to the Mac version. And since I don’t use a Mac for portable operations…that might make me rethink my whole writing workflow. I realize I am only one data point, so take that as you will.
Syncing via Dropbox with iOS is not an issue as Scrivener for iOS is using a special algorithm to save and update project files. Scrivener for iOS never overwrites your Desktop files. Scrivener for Windows/Mac take care of syncing your mobile changes without data loss. Syncing via Dropbox continuously two desktop PCs(Mac or Windows) might cause a problem.
@devinganger - Thank you for posting your concerns. Mine are similar, but you stated it better than I would have.
@tiho_d - Thank you for your clarifications, but I still have questions. Your advisory in this thread and your account of what L&L’s historical recommendations were seem distinctly contrary to the Knowledge Base article on Using Scrivener with Cloud-Sync services, whose second sentence is “However, the problems with storing .scriv projects on Dropbox have been somewhat overstated…”
The general message of the KB article seems to be: Syncing is inherently risky, but if you follow our recommended safe practices, you’ll lower the probability of an issue to reasonable levels.
Your message seems to be: Syncing is inherently risky, so don’t do it.
Am I misinterpreting you or am I misinterpreting the KB article?
ETA: @tiho_d: And the KB article doesn’t mentioned turning off syncing prior to editing a project. Your post is the first I’ve heard of it.
KB: “you’ll lower the probability of an issue to reasonable levels.” and I stated that it works 99.9% percent of the cases.
If you turn OFF Dropbox syncing during your writing session you should NOT expect any issues. If you have Dropbox running while you edit your project you have the amount of “reasonable level issues” as KB wrote, or the other 0.1% which I wrote.
May be putting numbers is not perfect in this case, but have in mind that I did not write 99% and 1%, but 99.9% and 0.1% on purpose to show that it is a very low probability, but still happens.
No one has ever stated that working in a shared Dropbox folder is recommended and is bullet proof. As I wrote two services which work on the same set of data is likely to cause trouble at some point. Hopefully not, but with the next update of Dropbox for example, who knows. The two services Dropbox and Scrivener do not work in cooperation, but completely standalone from each other on the desktop.
For experienced and sophisticated computer users this will probably work for years, without issues. Tomorrow a Scrivener newbie with little computer knowledge comes, and reads that Scrivener works with Dropbox without issues here in the forum, and next thing we get in the support queue is “Your st…id program lost my work. I want a refund. etc.” Believe me it has happened more than once and we keep on getting reports on data loss from users who write on a shared cloud location. Most likely it is due to some user error most of the time, but it does happen.
I will repost the words of a user in this thread: “There I have done it for many years(writing in a Dropbox project location) without problem (or, rather without problem as long as I was careful to let Dropbox sync before opening the project… learned that the hard way)”
There will always be another user who will learn this the hard way. Be careful guys.
After some reconsideration today we decided to do some further adjustments. The next version of Scrivener for Win will use the old algorithm(direct file write) when you work in your project in a shared cloud folder, and will use the crash-safe file save algorithm in all other cases. This will work only if you do not change the name of the root folder of your service Dropbox, OneDrive, Google Drive, iCloud. If we find “Dropbox”, “Google Drive”, “OneDrive”, “iCloud Drive” in your project file path we will assume that you are writing in a cloud sharing location. This should reduce the amount of troubles you experiencing when you write in a cloud sharing folder and give you enough safety when you write outside of it.
Thanks tiho_d, I appreciate the additional clarifications. I’ve been posting for a while now that people engage in syncing too lightly, without fully understanding the best practices or the risks, so I fully agree with you there.
As a Windows/iOS user, and someone who creates multiple zipped backups during a typical writing session. I’d prefer to leave the new algorithm engaged, even though I’m working in a DropBox sync folder. Can Win users continue have control over this setting, as with the current 1.9?
Hi Jim, having a user option to choose the algorithm was also our first idea. This might look like a good solution, but in real life choosing manually the right file save algorithm even per project is not, Sometimes your project is in a Dropbox shared location continuously, sometimes it is not. Sometimes it is moved/copied in and out of shared service location. Sometimes you send your project to other Scrivener users/editors who place the project in a totally random location. Having this option fixed even per project, might not be the most optimal one once you move your project. I am sure that many of you will forget to switch the file save algorithm and even a majority of you will say, I do not care, I do not understand these algorithms, just choose the best one for me.
Well we diced to choose automatically the file write algorithm, that is most likely to protect your project best, based on your project being in and out of a cloud sharing location. Writing in a Dropbox location which syncs continuously losing the last sentence since your last save, is not a tragedy. Dropbox has uploaded your last copy of the document already. If your project is outside of Dropbox, and OS/Scrivener crashes during document save with a direct file write is a tragedy as your complete document is wiped. In this case it is best to use crash-safe writing. Hope you agree dynamic switching of the file save algorithm is best.
The other big problem is that now we have a handful of users testing the Beta. You reported that you get the message occasionally. When the official version is released, we will get many more users experiencing this problem daily, which will come back to the support queue and this is also a long term support problem.
The solution now in Scrivener v1.9 is pretty basic one and is not as flexible as the one in the next Beta.
I bet you want the next Beta sooner than later now.
Thanks tiho_d, I see your point, although I think you’ve confused me with someone else, as I don’t recall ever seeing that message.
One thing I’ve seen on the boards over the years is posts from Win users who have an OS crash that somehow corrupts the (I think) XML file that contains the binder pointers. After their crash, the complaint is “all my docs are empty!” because the binder doesn’t point to the actual docs any more.
Does the New safe save improve that scenario? Or is it only intended to better protect the current document being edited?