I just wrote to tech support. Got an email they are very busy and it may take a few days to get to my question. Trying the same question here then. Has anyone had the same problem I am having? I just discovered that my daily Scrivener file has lost most of it’s data. The sidebar still shows all the same folder names and text names but when I click on them, they are now empty. Less than 10% still have some text in them and appear to have been untouched. The rest are completely empty.
I have been using this file as a library of sorts to journal, gather my research about many things. I was doing some backups to a different drive when I noticed that this had happened. I have never had a problem with scrivener before this. But this … loosing ALL your data? This is a pretty big problem. Using Disk Drill now to hunt for any evidence of missing files but I am still not at all aware how the sidebar structure can still be there and still have all the correct names - but be empty?
Scrivener’s automatic backups can be found by going to Scrivener -> Preferences -> Backups, and clicking the button to open the backup folder in Finder.
The list of files you see in the Binder is built from a master index file inside the Scrivener project. This index points to the RTF files containing your text, but does not itself contain anything but the names of the items. Thus, the most likely reason for the problem you are having is that the master index file does not match the actual contents of the project. This is most commonly due to a synchronization error: are you storing the project in Dropbox, iCloud, or a similar service?
I found a good one through preferences / backups, thanks. Really made me nervous though. I would love to understand how I got here and how not to get here again.
What I was doing was running a backup. I have been having trouble with my iMac and have an external drive I back up to as a mirror and boot from the external while the iMac is back in the shop (as is about to happen - again). So I have been keeping up with keeping one disk current and cloning the other back and forth. Using CCC because it always did a fine job. I have written to CCC maker Bombitch to see if their was anything that I missed setting up the clone. Should not have been as I have used that program for years. Then again, I have used Scrivener for years and this is the first genuine problem I have had.
Weird. But, thanks again for the tip to the right direction.
It is my understanding that if you work on a Scrivener project while you are making a backup of your hard drive, you are likely to end up with a corrupted Scriv project file on your backup drive.
If I understood what you were saying, it was when you were booted off your clone that you saw this problem. So it was likely due to the project on the clone being corrupted for the reason stated above. You were probably working on the project when you last ran CCC.*
A Scrivener project is really a package of thousands of files all of which need to be coordinated. If these files are changing as CCC is sweeping through that part of your drive, some of what gets backed up will be from one state of your whole project and other parts will be from a later changed state of your project. So, the index files and the content files get all out of whack in the backed up copy.
A great deal of what is so awesome about Scrivener is rooted in the fact that a project file is not one big document – but a coordinated set of files.
-gr
In fact, I do this all the time and do not worry about it, because I know that my Scriv backups in their backup folder are not subject to this issue – since I am never working in them, so if I ever needed to recover my Scriv project from CCC, I would pull its latest copy of a backup of my project.
OK, that makes sense. Thanks. Yes, I had the Scrivener file open while I was making the backup. That particular document is normally open all the time as I collect thoughts in it, do research, etc. Now that I am aware of this, I wont do that again. Next time I run a back up, scrivener will be quit first. Again, thanks.