Unfortunately, it seems that a few users are still experiencing data-loss in beta 023. Apparently, some users find that saving is completely failing to kick in so that when they go to re-open their project, they have lost the writing from their previous session. Obviously, we’re treating this as a matter of some urgency - we test each beta on our own machines before sending them out into the wild, but this one has never reared its ugly head in any of our own tests and, so far, we still haven’t been able to reproduce it. Lee spent a lot of time investigating and thought he had fixed it for 023, so we’re gutted that the problem is persisting for some users, but until he can reproduce it for himself on one of his own machines, he is essentially stabbing in the dark.
Because stability is of the utmost importance to us, I’d therefore like to offer a $200 reward to the first beta-tester who can provide clear instructions that allow us to reproduce the bug. Normally users try to steer clear of data-loss; we hope this reward will encourage someone to experiment and see if they can find a way of consistently losing their work. If we can reproduce the bug consistently for ourselves, Lee should be able to squash it.
The rules to qualify for the reward are simple:
First ensure you have the latest version of Scrivener for Windows installed (beta 023 at the time of writing) and that any previous versions were completely uninstalled (if you’re not sure, uninstall and re-install - this is just to ensure that no files from 022 are still lurking).
You must post the instructions as a reply in this thread.
Please provide the instructions as numbered steps so that they are easy for us to follow.
The instructions must cause data-loss every single time they are followed. So please don’t post to say, “Sometimes when I hit save and reopen my project data is lost” - we know that and are trying to find out the exact sequence of events that leads to this occurring.
Upon following the instructions, Lee must be able to reproduce the problem on one of his machines. Unfortunately it’s not enough that you can reproduce the bug - we must be able to reproduce it too, or we can’t fix it. It’s thus important that you state:
1.) What is your operating system (Windows 7, Vista or whatever)
2.) Is your account admin? (Understand that Windows 7 is admin by default)
3.) Where are you saving your scrivener project file?
4.) What format is the drive you’re saving the project to? (NTFS, fat32, etc)
5.) What is your ‘Save after period of inactivity’ set to in Options>General
6.) and as much relevant information as you can so that Lee can reproduce the same situation as closely as possible
Only one person will get the reward - the first person to provide clear enough instructions in this thread for us to reproduce the data-loss problem. The $200 can be paid via PayPal or direct bank transfer.
Thanks for bearing with us while we track this down - until it’s squashed we recommend backing up and exporting and compiling your text before ending each session, just to be extra sure you lose nothing important.
Backups don’t always work for this bug, as the text is not getting properly saved to the .rtf files, so be sure to check your backup before closing your project to make sure it contains all your text. Compiling is the most effective way of ensuring the data isn’t lost. You can include notes and synopsis text in your compiled manuscript by checking those fields in the “Elements” tab of the Compile settings.
Since text documents in Research are not included in compile, you may want to temporarily move any edited documents into the Draft folder so that you can compile them as well before closing, then return them to the Research folder. (You can also use Export or Print for Research documents, although be sure to check your exported document and ensure it contains all the text, as this may be subject to the same problem as the backup.)
Keith, a very good idea, and forthright as well. All fortune that someone can give you that sequence very soon, and you’ve given them the impetus to try.
Having not seen the no-save problem happening on 023, but also having a habit of being very careful how I do the upgrades, I have wondered if the secret to not having problems may be in the ‘not including any of an old 022 or earlier install’ part.
Maybe then some persons who have the no-save problem consistently now can be encouraged to do a complete Scrivener deinstall, and then, afterwards, trash the c:\program files\scrivener folder, if one is remaining (varies with earlier version).
To complete the process, such persons would do a then completely fresh install of 023, and note if they’ve still got the no-save problem with it. Or not, which would show something very important about how an installer’s deinstaller should work.
It’'s another avenue related to yours, in case it may turn up something.
Meanwhile, sensible is to use compile-to-rtf as MimeticMouton details in completeness, along with Scrivener backup-not-to-zip. Given this is a beta, I have always kept Scrivener text also stored in another way – in my case, that’s Scrivs to OneNote notes, but could as easily be MSWord pages. With Mouton’s notes-and-everything method, compiling to RTFs gives even more, and I’m doing that as it’s so easy.
For the team, the kindly thought which I know is accurate: ‘this too shall pass’. And thanks for all your work.
I tried that. I uninstalled Scrivener and installed 022. Then I installed 023 on top of it, and I still couldn’t get it to not save. (And I’d set the auto save function to something like 300 seconds.) Only way I could reproduce it was to kill the process without saving, simulating a crash.
Here’s an idea my fiance had: is there a way to verify the integrity of a project file? Could something in that have gotten corrupted and is causing the save issues?
garpu, I understand, and the experience is probably part of Lee & co. having such a tough time with reproducing this.
But as you may know, sometimes Windows installations can get pretty grotty, especially as far as permissions go, which would affect the ability to overwrite with fresh files.
Admittedly, I’ve mostly observed issues with this on registry entries, as compared to files, but not always.
Thus the point that someone who has the no-save problem actually do a forced fresh install, and see if that makes it go away. We would learn something, I think.
True…wine registries are far less crufty than your average windows registry. (There are a lot of system calls that wine programs aren’t allowed to do for security reasons, so they’re interacting differently than a program running on the windows. It’s not an emulator, just a different API. )
It could be a permissions issue, since I don’t have an issue with it–and you always have privs to your own home directory. But Windows 7 people had an issue with not saving. (And accounts are admin by default, I believe.)
In order to try to help, I went to do an uninstall; and according to Windows 7, I still have every version installed simultaneously:
But I really don’t have every version installed, because the prior versions bring up this dialog:
The strange thing is there are still a ton of files even after doing all the uninstalls. Here is the complete list: ListAsTextFile.txt
I’m going to go ahead and delete everything out of the directory and try fresh; but I have to wonder if that is really the problem other people are having – the fact that the uninstall doesn’t really clear out all of the old files.
I’ll do my best to create the issue; but I have not had it myself yet, so we will see.
I also had seen the issue of the multiple versions in add/remove programs and it was one of the main reasons I’ve been uninstalling, deleting all remaining files, installing newer beta. This could be key to the issue. I’d like to hear what happens when those experiencing the issue due a clean install. Perhaps we need a more thorough uninstaller!
There are two things here. Firstly, the previous version data remaining in the Windows control panel’s install/uninstall Windows. It is safe to remove these i.e. allow Windows to delete them when it prompts. I will chase up BitRock (the company that provides the installer) and log a bug with them. We had a previous bug with incorrect files sizes being registered in the same location which they fixed.
The other thing has to do with all the files that have remained behind after an uninstall in the install directory. This is meant to be that way as we really don’t want users to delete data/files unintentionally - even upon an uninstall. So, any files that were updated by the system or user after the first install is purposely left behind. So, if you create any files, projects, download dictionaries etc in the Scrivener install directory the uninstaller will not delete them and thus are recoverable even after an uninstall. You can always delete these directories and files yourself. We could always delete everything now that we are preventing users creating projects in the Scrivener folder itself, but I’m still reluctant to change this behaviour.
I’m not sure if I can be of any help to you, since it seems like you’ve determined that the non-saving issue is a known and expected problem for users who did not uninstall previous versions and right now you’re going after fixing the bug for users who did uninstall previous versions, but I noticed the bug early this morning and I thought any information I could provide might be helpful. I am a user who did not uninstall the previous version (or any previous version, in fact - I know how terrible that is, sorry) and I have been able to reliably reproduce the not-saving bug every time I’ve tried to edit and save a document.
1.) I'm running Windows XP Tablet Edition with up to Service Pack 2.
2.) My account is admin.
3.) I'm saving my Scrivener project files to C:\Documents and Settings\[my username]\My Documents\
4.) My drive is NTFS format.
5.) Scrivener is set to autosave after 2 seconds of inactivity.
6.) I can reliably reproduce the bug by opening Scrivener, editing the text of a document, and clicking save. Nothing happens, as far as I can tell. I've done this (saved) and restarted Scrivener and there are no changes, and I've done this and checked the .rtf file with a different program after saving while Scrivener was still open and there were no saved changes to the .rtf file. I've even edited the document, taken a snapshot, restarted Scrivener, and the document changes were not saved but the snapshot (with the edited text) was still there and could be rolled back to. There is, as far as I can tell, literally nothing I can do to make Scrivener save any changes whatsoever to any component of any file with a few very specific exceptions I don't understand. It does not save edits to the .rtf documents, it does not save edits to synopses, it does not save edits to document notes. However, it will save edits to my labels and label types, statuses and status types, and target word counts for individual documents, and it will save changes to my project notes. The strangest part of this, to me, is that as far as I know none of this was a problem before about 4 this morning. I have edits to documents from before that time. At that time, Scrivener crashed, and has crashed repeatedly since then. It has the saving issues both when it crashes and when I exit it normally.
I don’t know if any of this is helpful at all, but if it is, please let me know if there is any further information I can provide.
Thanks for the information. Actually this will be useful because it will tell us if a complete uninstall and reinstall of 023 fixes the issue. Could you please therefore go ahead and completely uninstall all versions (obviously take care to ensure that your Scrivener projects are kept somewhere safe and are not in any of the directories that will be removed during the uninstall), and then install the latest beta and let us know if this fixes it?
I uninstalled everything and did a clean reinstall right after I posted and have been playing around with it since then. So far I have been unable to reproduce any events of non-saving through any of the methods that previously produced it (and additionally, Scrivener has not crashed at all). When I check the .rtf files in another program, Scrivener appears to be saving correctly both when I explicitly instruct it to save and when it autosaves. It is saving changes to all aspects of my files and my preferences, which was not the case before. I also tested a couple of behaviors which usually make Scrivener crash or otherwise get angry on my machine – I created about 40 new documents, nested them all in one another, and input a bunch of text. This usually makes Scrivener behave pretty oddly, but it saved just fine and didn’t crash.
When I did my uninstall, I went and made sure the uninstaller appeared to be removing everything, which as near as I can tell it did, with the exception of things like backup files and project files. However, I’m not particularly computer literate, so I wouldn’t necessarily trust that there wasn’t a ton of stuff I just didn’t find. I used the uninstall packages provided rather than using Windows XP’s Add or Remove Programs feature. So, at least for my machine, a completely clean uninstall and reinstall made it so that 023 worked whereas it was having its saving issues when previous versions were still installed. I know that’s not very helpful to you for finding the bug, sorry Is there anything else I can do to help?
I think this thread has the most probable source of the problem. I was beginning to suspect a “DLL Hell” issue. I have to admit that I too did not do ANY uninstalls before new installs. One way that we might be able to track this down is to take a machine that has not been touched with Scrivener… at all, and install, one at a time, each version with no uninstall. Then just do a review of the resulting files. If there are ANY DLLs that don’t match the expected version for the latest install you WILL have unpredictable bugs. Also of note, the save issue I had with 0.22 showed itself right after a new installation. After I rebooted I was unable to miss a save again. I am suspicious that the old DLLs were still in memory (a holdover from Windows default behavior for legacy DLLs). For legacy DLLs (DLLs that are not in the new “Assembly” format) Windows does not check for expected version numbers at load. It just loads, or not, if one of that name is already loaded. This could easily explain why I had the bug after install but not after reboot.
If an old DLL was left installed for some reason (ie: file lock contention not reported by the installer) the bugs would persist. It might be a good idea to enforce a few things, such as 1) a forced deletion of any and all known Scrivener DLLs before install of the new, 2) a forced removal of all known Scrivener registry entries for DLLs/EXEs prior to install, 3) a post-install verification of DLL/EXE size, hash, file version, and registry entries, and 4) a forced unload of all Scrivener and direct dependency DLLs from memory (ie: QT, QSQLite, MultiMarkdown, doc2any, etc…) This will help to ensure that there are no unexpected bugs from Microsoft’s oh so well designed… cough…cough… well, you know the rest…
I think you may be able to reproduce the no-save effect by installing up to 0.21, running Scrivener 0.21, adding and saving some data, installing 0.22 (no uninstall or reboot), adding and saving the data, and then rebooting. If I’m right, you will probably lose the second batch of data added after the 0.22 install.
Just to say, those sound like very useful thoughts, Randy, and even more than I could muster here.
I did look last night at Lee’s architecture, and at some capabilities of the installer package – I think it could do many if not all of the things you mention here, and good to be doing them.
I’d wanted to understand why Lee felt he didn’t want to wholesale remove the progdir/Scrivener directory, and found probably enough of the reasons to support this. Aspell dictionary customization is just one of them, and for this and other packages, having his own copies under his own structure makes a lot of sense for quality of Scrivener delivered. Writing of projects to the install directory shouldn’t be done, and I think is now prevented by Scrivener as well as by later Windows, but probably some people in early versions of both have.
You’ve written in more detail than I thought to about very good things to have the installer do, so that the Scrivener code and configuration is fully and dependably updated, without needing to drop the folder. It should be a very good help.
I’d beaten up 023 pretty severely last night, and with the clean install, could not make it budge off the safely saved line. That and others results are really building the confidence here that 023 itself is solid.
As a better option, Lee could use the local AppData directory… Actually, I just looked and he is already using both a “Scrivener” and a “Scrivener HQ” directory under there. I think it would be a good idea to move all of the personalized settings under there so that the program directory CAN be wiped completely. The ASpell personalization can also be backup up there periodically and checked at install for restore.
1.) I’m running XP.
2.) Admin account.
3.) I’m saving it to C:\Documents and Settings[username]\My Documents\Scrivener. Subfolder named “Scrivener” in My Documents folder on my computer.
3a.) The drive is an NTFS.
I haven’t been able to get Scrivener to do it again, but I also did NOT uninstall 022/ reboot before I started working with 023. Since I rebooted, I haven’t had any issues.
I’ve also been trying with small blocks of text- a sentence or two. Most of the posts I’ve seen about this problem have been about losing at least few thousand words. Maybe the amount of text makes a difference? Just a theory.
For anyone who wants to do a COMPLETE uninstall leaving NOTHING, not a single trace, in the registry, should use revouninstaller: revouninstaller.com/revo_uni … nload.html. This is an excellent program that allows three different levels of uninstall – two of them past the normal uninstall of programs. It has a free version that does the job and a pay-for version that I am unfamiliar with. Both are listed in the above link.
I would have to say that Randy’s probably hit the issue at it’s root. I’ve attempted to reproduce the issue myself, but have not had any issues at all. In my particular case, every time a new version of Scrivener is released I uninstall the old version, and then delete all Scrivener folders in Prog files, all Scrivener folders in My Docs, and then delete any leftover registry entries prior to the new installation. I’ve not had any issues with non-saving.
I’m using Windows 7 Professional 64bit, my account is the Admin account.
Just a note as well - am I correct in guessing that most all of those with loss of data after alleged saves are saving their projects in places other than the Prog Files directory (or Prog Files x86 for 64 bit users)? The default saving directory of Scrivener is the My Docs folder, so I’m just curious.
If we can reproduce the bug consistently for ourselves, Lee should be able to squash it.
)
Is there anything else I can do to help?