Hate to ask, but you still storing your projects on iCloud drive (or similar)?
Is the project you are trying to piece together one you already know got chewed by your remote drive service (or whatever)? In which case, you should not be surprised if Scrivener’s recovery function could not just somehow save you from what that service was doing behind the scenes.
If memory serves there is also a long history of your getting lots of diagnostic help with the troubles you had. Worth mentioning when lots of folks put in their good time (and most of them just knowledgeable citizens looking to lend a hand).
Have you been making sure to close Scrivener and let it sync completely before opening it on a new machine? This sounds like what happens if a Scrivener instance detects a project’s files changing underneath it because of a hasty sync or the project being open in multiple places.
I am not sure there is any multiple machine use in the scenario.
But also I must not be up on the latest about iCloud, but even so, for this ‘frustrated and confused’ user, better-safe-than-sorry advice is probably the best kind anyway. Use of iCloud storage (set to remove files) was one of the problems Randall had back when.
As far as I know, iCloud is still a no-no. And that’s regardless of whether you’re even using Scrivener on a second device. In my experience, even just storing the projects in iCloud can cause issues.
Only ever used one machine, but I did purchase the iOS version for my iPhone. I immediately learned that the iPhone was not the place to write or edit a serious manuscript.
My use of iCloud and Dropbox with scrivener’s automatic saves and backups was in direct responce to Literature and Latte advise and the in-agreement advise of other Scrivener Tutorial programs… I did so in the interest of safety and the security of my writing.
If it’s lost, it’s lost. I think the advice given now is in the way of preventing this from happening again.
If I understand correctly, you could:
perform frequent in-app backups to another folder
perform frequent system-wide backups using Time-machine.
perform frequent system-wide backups using third-party software such as Arq. (I am currently using version 5, which works perfectly).
it is a good idea to back up to at least i. one external local drive and ii. one external remote location (e.g. Dropbox, Gdrive, Onedrive).
perform frequent folder backups using Arq (at a two-hour interval, for example).
use Git to commit often and push changes to a private Github repository. This isn’t necessarily ideal for Scrivener projects, as you won’t be able to use diff tools, but it works, nevertheless.
Never use iCloud, Onedrive, Gdrive, etc. to store your projects.
All of this is probably overkill, but one can’t be too careful with one’s work.
Saving and backing up are two very different things. Scrivener’s automatic backup system, by default, will back up your projects in the form of ZIP files, and that means that you can essentially back up anywhere with minimal risk of project corruption. However, you need to be more careful with where you choose to save the live project (by live project, I mean the file with the .scriv extension that you are actively working on). While it is possible to save live Scrivener projects to any cloud-sync service, Dropbox is currently the only one we can recommend (and even with Dropbox, it’s important to follow these fairly common sense guidelines to avoid syncing conflicts.) If you find your live project corrupted and you keep opening and closing it in its corrupted state, fresh backups will be made of that corrupted project and the viable backups will be replaced by the bad ones. It sounds like that’s what’s happened here.
You mentioned both Dropbox and iCloud, so I’m not sure which one you’re using, but can I ask: is there a reason you’re saving the live project to a sync service, since you’re only using one device? The safest route for users who are not syncing their projects between devices is to just keep the active project on their hard drive and keep their backups in a remote location like a cloud drive (again, it doesn’t matter what cloud service you’re using in this situation because we’re dealing with ZIP files).
I set up Scrivener with Dropbox exactly as Literature and Latte said to set them up. I used them exactly as Literature and Latte said to use them. You can’t ask your users to take actions to protect their work if said actions actually endanger user work.
I used DropBox for automatic backups. I used iCloud for tertiary backups of those DropBox backups. I used Dropbox exactly as Literature and Latte recomended in their how to vids. This notion that problems must be the user’s fault is absurd. Scrivener rebuilt my document structure. DropBox didn’t. Scrivener new decided to build a new folder in my project’s binder called “Recovered Files” and to move document and document fragments from other places in my project’s binder, into that “Recovered Files” folder and to append the phrase “(Conflicts)” to these document names. In many cases, these documents are fragmented and in no way represent the actual state of those documents in the most resent save (prior to the curuption of the project). Many of my project’s binder documents are completely missing. I manually made copies of the dropbox stored backups and moved these to a special folder within my mac’s iCloud iDrive shared documents folder. iCloud performed this function correctly and consistently and without problems. Neither Dropbox nor iCloud seem at all to be the problem. The problem was with my primary Scrivener projects (not the backups), and those were being saved locally to a folder within my root user folder (my user account).
Apparently, I did not notice this problem right away as my manuscript is large, has many tens of binder documents, so the “Recovered Files” folder was deep down at the bottom of my scrolling binder area. Scrivener sent no warning when this occurred.
If this was a year ago, I think it’s safe to say that no one in this conversation has any way to determine exactly what happened, short of spending money on forensic analysis of the drive. (If then.)
If “Recovered” or “Conflict” files were created in the project, then a synchronization error occurred. The exact cause and nature of that error are likely impossible to determine at this point.
Generally speaking, ZIP backups are safe with pretty much any cloud service. Unzipped project folders expose the contents of the project, making them more vulnerable to damage. We recommend having multiple backups for critical data.
The “Recovered Files” folder is created when the project is damaged by a third party tool and Scrivener discovers orphaned files upon loading up the project. The most common cause for that problem is if the project is stored on a cloud drive and is accidentally edited twice without fully syncing (so yes, user error is often to blame). By creating that Recovered Files folder, Scrivener makes it easier for you to see which parts of the project conflicted when that syncing error happened, so you can sort out those conflicts by hand. So given all of that, it’s safe to assume that there was a syncing conflict, but as kewms mentioned, it’s impossible to know the exact circumstances if this happened that long ago.
I do hope you read and also followed all the guidance in section 14.1 of the Scrivener User Manual. Three simple rules that should be known and followed by all Scrivener users who chose to put their files in a folder synced with cloud-based services.
I feel for you. I haven’t had a transfer loss, but I’ve had dozens of backups full of holes.
Dropbox + multiple machines a few years ago taught me never to save direct to the cloud. All it takes is one machine’s program not loading the entire file, then saving empty chapters over the copy in Dropbox.
