And I would encourage anyone experiencing this kind of problem to contact tech support so that we can work through the issue in more detail.
Unfortunately, any problem description that begins “I hadn’t used Scrivener for XX period, but when I went back to it…” inherently implicates a non-Scrivener issue. Scrivener doesn’t leave anything resident in memory when it isn’t running, and so has no ability to do anything – positive or negative – to files while it is closed.
Dropbox, on the other hand, has vast powers to manipulate your data. Even when your computer is off, the copy of your files on the Dropbox server is still accessible to anyone with access to your account, and any changes they make, however misguided, will automatically propagate to your computer when you power it back up.
At the same time, Dropbox has no inherent knowledge about OS X, the Mac “package” format, or about Scrivener projects. If a user asks to rename a folder to “Scrivener app.scrivx,” “Scrivener.app,” or something equally misguided, Dropbox will obediently do so. In my experience, the most disastrous Dropbox-related faults generally involve someone trying to open or edit a Scrivener project via the Dropbox web interface, which exposes the underlying structure of the project but (unlike Windows Explorer, say) is not well-suited to folder/project level file transfers. For example, an incomplete synchronization might lead to Scrivener trying to open an incomplete project. The user might then try to “fix” the resulting error message via the Dropbox web interface. I don’t have enough information to say that’s what happened here, but that’s the direction in which I would look.
This is why Dropbox alone is not a trustworthy backup solution, and why I recommend sending Scrivener’s automatic backups to a non-Dropbox location. (For more extensive thoughts on backup strategy, go here: Got a backup?)
Katherine