I have the same problem with this new version. I’m running windows 7 (32bits) and all the work carried out yesterday is today gone. I searched for the changes in the folders, but nothing, one day of work LOST!!! I’m desperate, someone has found a way to recover the data? Wonderful sotfware… but now it’s giving me a hell of a day!
I’ll chime in here. Wrote for an hour or so, thought I had saved but when I came back the changes were gone. Redrafted and wrote for another couple hours to finish out a chapter. Created a new chapter, tapped on the index card to write a tiny blurb about the upcoming chapter and Scrivener just shut down completely. I thought for sure that I’d lost everything I’d written, went to the folder and checked the .rtf file for the last chapter but it looked okay. Relaunched Scrivener and found that the previous chapter was still there. Then I added a few words to the new chapter, successfully add the blurb. Saved, and closed the program.
This morning, the new chapter was empty, and the blurb gone.
After reading about the problems I’ve compiled the book out to a Word .docx file, I think I’ll keep doing that after each session until the I read that the save problems have been addressed.
How does scrivener manage the files? It always overwrites them or works in a similar way to Microsoft Word that uses some sort of “temporal files”. Maybe if that is the case in Scrivener there is a possibility to recover the data… using a recovery data tool? I don’t know…
I’m surprised not to see a response from Literature and Latte on this matter, as it’s a pretty serious issue. The last thing Scrivener needs is any hint at losing data!
Well I guess they’re very busy right now or maybe they’re already into it, I can’t say. I only want to know if there is any possibility to recover the data lost because if weren’t I’d stop losing my time too. Anyway, it is not easy to re-write everything because this is not a mechanical task…
Andrew, according to Lee’s latest update (Re: 9th APRIL - LEE’S UPDATE - BETA 022 RELEASED), he’s actually already working on a lot of the bugs that has been reported for 022 and he’s planning to release an update with as many fixes as possible later this week.
The saving problem might have been gotten confused/lost with a report of another bug (where changes are not saving after a project search and replace). A lot of us have already followed-up and alerted Lee that he might be dealing with two problems instead of one; I’m confident he’ll be aware of it, if not already.
The biggest problem, IMHO, however, though is that aside from people all confirming that “yes, I’m experiencing this problem” is that no one has been able to reproduce this problem consistent or deliberately. No one has any real idea what’s causing it (or if the project search and replace scenario is a related symptom or something different).
If Lee can’t replicate it on his end, he can’t fix it.
It’s a weird situation where I’m now constantly watching my .scriv/Files/Doc folder hoping for files NOT being saved to disk. 
Scribbles.
Fair point, let’s just hope it get’s sorted soon as it’s such good software. I use the Mac version all the time and want to use the Windows version when away away from home.
I am sure he will fix the problem eventually, my question is: ¿is there any possibility to recover the data I lost? I don’t know if it scrivener didn’t save it or save it in “temporal mode” and then didn’t save it properly… Someone who has more knowledge about how scrivener manage files and saving could tell us if we would be able to recover the data lost (I am sure I write/edit/delete a lot of words yesterday, they were on the screen, the * seemed to work properly appearing a dissapearing…those word were only in the computer’s RAM memory, is not there a caché for scrivener?)
Difficult to say, because AFAIK, no one knows what the problem is, specifically–just the end result.
You might want to take a look at How a Scrivener Project is Structured.
Right now, I’m checking the .scriv/Files/Doc and checking if the changes have been made before closing my Scrivener project. My hypothesis is that the changes are not being written to disk before closing, so when the project is closed and re-opened, the original file is loaded and all changes are lost. But I haven’t been able to prove that. It could be something else. Perhaps the file is being written elsewhere. Perhaps it’s being written and the original is being re-written over the changes. No idea. I’m making backups of my projects at the end of the day, opening another instance of Scrivener them to verify the changes are there, and then only closing both instances. It’s a bit of extra work.
That’s not entirely true: as described above, I have replicated my version of the error. In any case, it might be worth to make an exception for such a vital issue like this and try to find a reason for the error without being able to replicate it, even if it means thoroughly checking how saving works in 0.22.
I think what Andrew wanted to express is that people who lost a day or so of their creative work might be reassured and encouraged to further use and eventually buy Scrivener by a little post in this thread saying “Thank you, we are working on it.”
Right, it’s the lack of reproducibility. It doesn’t always happen for everyone so presumably there’s some trigger earlier in the session that causes the work to not be saved. Finding it is the key…just a hard one.
Yep. Me tooooo. So far I haven’t seen it at all. 
To throw some questions out there…Has this happened on new projects (created in 022) or only older ones? Are they large projects? Has it only happened after a lot of editing in different documents (moving around in the binder, using document history in the editor, creating new cards on the corkboard)?
Also, has anyone done a Windows search for the missing words, just to confirm they aren’t being saved somewhere?
I agree.
Awesome! (Er, for certain values of awesome.) How do you do it?
Oh, definitely. I didn’t mean to speak for Lit & Latte, or to say that this issue isn’t worth looking at until we could prove we could replicate it. Sorry if I gave that impression!
I’m saying, however, the most ideal way we can help is to provide Lee with information so he can replicate it on his end, and then kill the sucker that’s causing it. 
Sorry, Elminster, I’ve tried your steps, but didn’t get it to replicate. 
Are you able to always trigger it? Am I doing the steps correctly?
- Make changes in various places in my project.
2. Edit a folder text - have I interpreted right that this was what was triggering it? - Make changes in other places
- Close
- Reopen
As I described in my initial post here. I obviously don’t know whether it “works” for anyone, or whether it’s the same error, but, as I had written above, the error is consistent, and I had it on both of my machines. But who knows, maybe it’s just that particular project (I am accessing the same files from both machines via Dropbox). I will try to do some additional “testing” when I find some time.
No problem - I apologise if it appeared that I wanted to start flaming.
I agree. I might as well start the testing now.
waves truce flag! It’s obvious to me that we both want this bug to die quickly and are on the same side. 
Good luck! Also, if your project is consistent with your steps–then this might be a really, really good thing. You could send it to Lee (if both he and you are agreeable) and that might just do the trick.
Okay, it’s late for me here so turning in now. All the best to the testers out there.
Yes, that is correct. Though we might not have the same idea regarding what a folder text is. I mean the text which is written “on” a folder as if it were a text document (if that makes sense). Oh, and my folder has documents inside it as well. Sorry if I gave the false impression, I am able to replicate it in a specific project, I never tried it with another one.
Hi all.
My copy of Scrivener is also not saving properly, despite doing manual saves.
(Right now I have been backing up my information by hitting compile at the end of the day, which is not ideal, but at least the words are there. - And compile seems to be doing weird things to the right hand margin, but I haven’t configured it yet, so that might just be me.)
I am running Windows 7 Pro 32bit. Two nights in a row, I wrote throughout the day (manually saving regularly, because I’m paranoid like that). At the end of the night, I saved, (and last night compiled), closed Scrivener, and either shut down or put the computer into sleep mode. The next morning when I open Scrivener, an inconsistent amount of writing is gone. Usually it is everything from the last few hours, but stuff that I did in the morning is still there (I tend to leave Scrivener up during the day as a sort of reminder to get back to it when I’m off work.)
Looking at the files, the RTF files show the correct time for the last save, but when I open them, they are still missing the words.
The compilation file is, thankfully, untouched.
If it helps, I am also saving directly into my dropbox folder because I work between two computers, although I have only used Scrivener on the laptop running Win7 Pro.
Drat! I thought I had reproduced it following Elminster’s steps–watching the activity in the Files\Docs folder, it updated when I added folder text but then did not update when I added text to another document (which already contained text) or its synopsis. Auto-save did its thing but nothing happened. But when I then closed the project, the changes all got written and were all there when I opened the project again.
Repeating this, I noticed the same behavior but when I paused to go click around in Windows Explorer, it updated there, so it seems that Scrivener really is saving and Windows Explorer is just being lazy and not showing me the updates in real time after that first folder. Anyway, so I’m sharing that for anyone else who may be monitoring the folder and getting excited…
Did discover, however, that if you try to close a project while the focus is still in the synopsis text field, Scrivener crashes. So I guess that’s a win. Sort of.
This is on Win7 Pro 64bit.