I did a lot of preparing and outlining in Scrivener and just now finished everything for the start of my final writing… and now Scrivener started to act weird: one document in the binder was without text; a webpage url could not be opened anymore and suddenly the program closed. After trying to open it again, Scrivener told me that it needed to update to an other version or something like that because this file could not be opened. Importing an update doesn’t work and now I only get “THe application Scrivenr quit unexpectly” errors.
I was finishing up the outline, like moving around folders and files in the binder, turning folders into files. At some moment I checked on of the text documents and saw that there was no text inside. I saved the project, opened the project again and got the message the it could not be opened because it needed an update of some kind. Now when I try to open Scrivener I get an unexpected error and it closes. The file size after zipping is 11 mb, I’m not sure how to send this. It’s to big for hotmail.
Yes, it’s on my external drive. Actually, during the writing proces, my external drive became disconnected for a while. (My cat sat on it and pulled the power cord). I connected it again and continued writing.
I made a complete template of this project at the beginnng of my writings. Now I was able to open an old version of this project from some days ago and copied them into my template. So the only thing I lost is the writing itself that I did , not all my research info. Still not a good feeling to louse so much work. I’m not sure what the reason is but it happend just after I reconected the external drive again, so maybe scriverer tried to save but could not, it however didn’t gave any message that it could not save.
That could well be the source of your problems. I strongly recommend not running Scrivener projects from an external drive. Scrivener projects are not like regular files. Regular files are all loaded into the memory of a program, which means that if their save location is lost, the program still has all of that data in memory. Scrivener projects, on the other hand, because they can potentially contain thousands of files, are only loaded in parts. Only the files currently in use are loaded into memory. Thus, if the saving location is lost, Scrivener only has a limited number of files in memory that it can save. I’m not sure what happens when an external drive’s connection is lost, but from what I hear it is not good (from other users too). Whatever does happen is handled internally by OS X, but it sounds as though after the connection is lost, it does not pass the correct location back to Scrivener again. It may be that the mount is assigned a unique internal number to identify it to OS X, and if so, this would mean that OS X would not know that the path was actually the same… And might lead to Scrivener overwriting the original project with only what is in memory. This would make sense in light of what you have said. The fact that it is saying that you need to upgrade suggests that the file inside the project that holds the version information is lost - and that file would never be held in memory.
At this stage, I hope you backed up your project. I am looking into whether there is anything I can do to make it safer to use an external drive, but in the meantime I recommend always working from the local drive.
This is what’s known as a wildly mild understatement. It is disastrous to turn-off or disconnect a drive when there are open files on it. There are multiple reasons for this warning but the most dangerous is caching. When you save a file, it is almost never directly written to disk, it is first cached in memory and then when the drive has time free it is written to disk. These days, there are often two caches: one maintained by the operating system and one maintained by the hard disk itself. If you disconnect a drive without formally “ejecting” it there may still be writes waiting in the queue and those will be lost forever when the driver for the disk is closed because communication has been lost. Caching is good—it speeds up disk reads and writes but in this case it is very, very bad. Database designers ameliorate the risk by forcing the cache to flush at the time of writing but this really is a special case.
As you point out, Keith, because a project contains multiple files and you are performing summary operations on it when the project is closed this makes Scrivener projects more vulnerable to this kind of corruption. Internal drives will be safer because they are protected from babies, cats, dogs, mongooses, feral pigs, and mildly inebriated users but the same thing could happen with the internal drive if power is cut to the computer itself. I’ve been running externals with really heavy file I/O for years with no difficulty but they are deliberately placed to minimize the risks.
Now you’ve made me nervous. Tell me, please, that it’s OK to drag a Scriv project from documents in my home folder to my thumb drive and then drag that on to my documents folder on another laptop - and vice versa. But thank you so much for explaining why I should eject it properly first - I believed it was just some authoritarian rule.
Don’t worry, dragging your project to a thumb drive and then dragging that copy to your documents folder on another computer is perfectly safe. In that instance, the original copy on the first computer remains untouched, so even if copying to the thumb drive files, your original project is safe. Then after you have dragged to another machine and work from there, you are working from a local drive again, so it’s as safe as possible.
The trouble only occurs if you work from the copy on your thumb drive rather than from a local copy. It wouldn’t be a great experience anyway, because working from a thumb drive tends to be painfully slow (because Scrivener does a lot of loading and saving on-the-fly). But if the thumb drive lost its connection whilst you were working, then you could lose work. But if you are working on a local copy and just using the thumb drive to transfer the file from one machine to another, then there should be no problems.
I have spent the morning working on making this safer, too. Now, as of the next update, if Scrivener cannot find the original file package when asked to save, it writes out all open documents, notes, synopses and project notes to a “recovered project” directory in your Documents folder, displays a warning message, and then closes the project to prevent further harm. This should mean that you don’t lose any work, as you can just re-import the recovered files into the original project. Nothing is ever going to be 100% safe when it comes to external and network drives, but this should at least save users from losing work in 90% of such cases (I hope).
If you’re as good a teacher as you are at making and supporting Scrivener, and I bet you are, then I look forward to them being in charge of the world. Not that anything wouldn’t be better than what we’ve got now, but Blount-taught kids will be the business.
That’s interesting. The books editor of the FT got in touch with me recently to sort out an interview about Scrivener for an article on writing software, but then she said she didn’t need me because they were focussing on a different type of software - the sort that gives you prompts and “helps” you write (NewNovelist etc). (Thanks for mentioning Scrivener!)
Yes, she asked me about those and I said I didn’t work like that, and then I launched into Scrivener as the non-authoritarian, elegant, seriously useful etc etc. She did sort of laugh, I recall now, when I said that, but she asked more about it. Interesting to see what turns up.