Sorry we haven’t managed to get back with you yet. It’s been the weekend, and on top of that we’re a few days behind the curve still, with the big launch and all.
I have a few questions, and hopefully in investigating them they help you track things down:
Does that mean you have the folder in the Backup preference pane pointed at Dropbox? Is the project itself also on Dropbox?
While looking at the preference pane, how do you have things set up there? Since you mention opening the project on your Mac when this happened, that probably means it was closed recently, and under default settings that would mean a backup should have been created automatically. Despite, you have this to say:
There is nothing at all? Again defaults would be to have at least five redundant copies of the project from the last five times you closed the project. Are backups not being created for this project?
If so, is the project in the backup folder? If not, do you have the project excluded from backup in the File ▸ Back Up ▸ submenu?
As to the rest, the only part I’m confused over is how you compiled to PDF on another computer without opening Scrivener on that computer. The other things in your list don’t seem to involve using Scrivener at all, so it is unlikely they have any bearing on the matter.
Backups and all of that aside, if you truly only have one copy of this project in the whole world, then the approach I would take first is to right-click on it in Finder and compress it to .zip. That preserves it in its current state. Now you have two copies—hopefully you’re never reduced to one again!
Now, right-click on the project again and choose “Show Package Contents”. You’re looking for files that Dropbox has tagged conflicted. In particular, is the .scrivx file in the root level of the project folder conflicted? Is one of those conflicts maybe a month old? If so that would explain a good deal. If that’s the one Scrivener is trying to open then it would have a month’s old picture of the project to work from.
It would be worth going through every folder in the project looking for similarly conflicted files. I know you mentioned the project is never opened on the other machine—but it’s still possible for Dropbox to get confused even with only one computer.
My order of priorities would be:
- Isolating the cause and trying to patch together a repaired copy of the project using the Dropbox conflict data.
- Before even opening the repaired project once, making sure my backup policies are solid with a couple of test projects. I would want to see new backups created precisely as they are set up to do, verifying they appear on the disk.
- Ensure backups and working data aren’t all stored in the same basket. If you back up to Dropbox, consider keeping the project local. It’s far less complicated on your disk. Since you never open the project on the other computer, the large increase in complexity (and thus opportunity for machine/human error) for storage is without purpose. For those that want the project accessible in multiple locations, then I would advise keeping backups on each machine local.