The last three months I’ve been fighting this same issue. My work is one long text document that I go through and create folders (chapters) and text documents (scene) with each chapter text.
Every few times I open (or compile) one or more of the sub text documents will simply clear. The document is there, the title / name is there but all the text is gone. When I first click on the document it shows the graphic icon that indicates it thinks text is there (squiggly lines on paper) however, when I click on the doc it is blank.
I have started compiling before I exit, but even then the compiled output will be missing entire chapter(s) even though they were clearly present when I hit compile.
It has never been the full document and once a specific chapter/scene erases it will continue to do so (though not every time and not always that one). So for example if Chapter 16/scene document goes blank on Monday it will go blank on Wednesday as well, but Thursday it will be fine and Friday it will be Chapter 12.
I started a new document set and copied thinking it may be some index issue, but the problem still happens.
Any suggestions on how to stop this would be great. I can’t continue to work with Scrivener when I end up loosing 1/2 my time to trying to restore lost text. It is especially bad if I don’t notice a chapter gone for a few days because then my backups tend to contain the issue as well.
Platform: Mac OSX 10.7.5
I’m running everything local, close down the application every day, and not using scrivenings (sp?).
Is there anything about where the project is stored that you can think of that might be causing this at the file system level? Projects are really bunches of files inside of a package style folder, and so sometimes third-party utilities can mess things up if they are configured wrong or are given confusing information about what they should be doing. A common scenario these days is Dropbox (or similar services). Outright data loss is uncommon with Dropbox (what you usually end up with are conflicted files causing things to revert to older versions) but it’s not entirely impossible to imagine how a third-party utility like this that is designed to keep a folder synchronised with other computers could get things wrong now and then. If you suspect that might be the problem, please read the chapter in the user manual (13) on how to use Dropbox in such a way as to mitigate these sorts of problems.
Another type of software I have seen causing issues like this are programs that claim to keep your Mac clean. Unfortunately some of them take their cleaning a little too far. This is especially so when things are stored on the Desktop. Because the Desktop isn’t designed to hold thousands of files, a couple of these products come factory defaulted to clear old files out. Once again, since a project is just a folder with a bunch of files in it, to such utilities and old chapter just looks like an old RTF file to it. So it deletes the file and you see the text vanish from the project. If you’re using anything like that, (a) move your working projects out of the Desktop, like I say that’s not a good place for long term storage and (b) check the configuration settings in the cleaning product.
Compiling would reveal this issue as it occurs, because compiling goes back to the disk. In other words you can be working along and stuff like one chapter might be stored in RAM while you are working. Then something comes along and deletes the RTF for that chapter while you are working. You can’t see that it is deleted because the RAM copy is still there. When you compile it goes back to the disk copy and that is when you are first aware of the blank data. That the icon had text in it prior to clicking on it mean Scrivener did have data in the search index when the project was loaded. It goes blank when Scrivener realises there was a fault in the index and “corrects” it by blanking it out.
The only known data loss bug in recent history that was Scrivener’s fault is the one you specifically mentioned you shouldn’t be encountering: the Scrivenings bug when the project is left open on that session for days at a time. That doesn’t mean there isn’t another one we are unaware of, but I’d check these other two problems first. Nine times out of ten, when people lose data spontaneously it’s because of something messing with the internal files behind Scrivener’s back.
Thanks for the detailed response. My issue has gone from once a week to daily. In fact my hour a day of writing has become 10 minutes of writing and an hour of recovery.
I don’t run drop box, but I do run SugarSync and have been since long before using scrivener. The dropbox scenario you described could reasonably be the same for SurgarSync. I’ll disable syncing on all my writing folders and see if that makes any difference.
Yes, SugarSync is going to be vulnerable to all of the same issues as Dropbox.
Once a project has synchronization conflicts, the problems can tend to get worse and worse: the synchronization software is convinced that the copy you are using is “wrong” and keeps trying to fix it.
So I would suggest moving the project out of the SugarSync-accessible area and doing a little cleanup. I’ll bet if you look, you’ll find a lot of conflicted files. (Right-click on the project in Finder and select the “Show Package Contents” option. Conflicted files should have some kind of naming convention that makes them obvious.)
Drag all of the conflicted files out of the project. Then open the project in Scrivener, and inspect the conflicted files one at a time to see which ones have material that you want to keep. (You can either re-import them using Scrivener’s File -> Import command or open them in TextEdit.)
Once you have a good copy of the project, delete all other copies and make sure they are gone on all the computers SugarSync connects to. Then move the good copy back into SugarSync’s folder.
Sorry for the delayed response. I was away on vacation and didn’t have internet access.
I appreciate the suggestions. What you say makes sense to me in theory, but I don’t have Dropbox connected at all to Scrivener. Just to be safe, I checked it and there are no Scrivener documents nor anything related to my work in there. I don’t have any other kind of cleaning utilities.
I do have Apple Time Machine running. Could that have something to do with it?
Again, SugarSync is vulnerable to all of the same issues as Dropbox. The same advice for resolving synchronization conflicts applies to both systems.
I’m a little confused, though. Are you the same person as icodemarine? I was addressing that person’s problem; if yours is different, obviously other suggestions might be more relevant.
I’m having exactly the same problem that the OP outlines. Using dropbox.
What is the best practice for hanging onto a file? Feeling pretty frustrated. This has happened a lot to me (have lost a lot of work on Scrivener through corrupt files etc.) It’s a shame.
If you choose one of the two strategies described there (and stick to the ‘never have a project open on two machines at once’ warnings) you shouldn’t experience any problems with Dropbox – I haven’t and I’ve been working that way for a couple of years on three machines. (That of course doesn’t mean that some other factor can’t cause problems, but the basic workflows for use with Dropbox are well established).