Today I lost approximately one month of password changes (irregular backups strike again, and for this I expect no pity; I should know better by this time). However, I am wondering why this happened, and whether there is any way to recover my lost data.
Specifically, when I logged off from Windows (Vista Business x86 SP2, which may be relevant) with an unsaved database, KeePass asked me if I wanted to save it; I answered yes, and that was the last dialog or prompt I saw before the computer logged off 5-15 seconds later. That is, Windows did not pop up its prompt about a slow program halting its log off process, as Vista frequently does (Vista seems to have cut the timeout from 20s to 5s, for presumably performance reasons). Therefore, I am puzzled why an 80+KiB file was truncated on save to 222 B, as in fact happened. Surely KeePass could have finished writing the file in the time available, or at least displayed an error!
Another quirk I do not understand is the apparent willingness of KeePass to overwrite databases without any guarantee of integrity -- there seems to be no concept of transactions. Word, for example, when it saves a document, saves it first to a temporary file, then deletes the original and renames the temporary to the name of the original. How hard would this be to add to KeePass? (Yes, I know, I could "write the code myself, if I want it so much". I don't think I have enough time to write the code, and the tests, and test everything exhaustively to make sure it works, and send it in, and run through the whole check-in-by-proxy process, and then debug it some more, and so forth.)
P.S. I have now set up an automatic backup system, roughly as outlined by pail459 in the other forum. So my future databases should not have this problem. (Famous last words....) Still, I think this is a valid feature request.
This is really a problem with Windows aggressive shut down process - the marketing types don't want Windows to take too long closing, it might make people think it's less efficient or something.
Dominik may have some ideas on ways to make Windows wait a bit longer for the save to complete.
Fully agreed on Windows marketing and all, and I'm sure there's a hidden half-supported registry entry I could set to make it take longer, but the more general problem is, why does KeePass allow its databases to become corrupted if it's interrupted in the middle of a save?
Check out the Auto backup thread for suggestions on backup on start up.
Done that yesterday ;-)
Thanks for the suggestions, Paul, in that thread and this.
Both KeePass 1.17 and 2.09 will support and use database file transactions by default (by writing to a temporary file, deleting original and renaming).
Another thing I've noticed recently, separate but related, is that config files have a similar habit of getting messed up on shutdown; I have to keep a copy to restore in case the config gets reset to defaults. Hopefully similar techniques could be applied to this file as well? You'd probably have to customize .NET's Settings support, though....
Maybe I should just work out a patch for that and send it in, if you haven't already done it. I'll see if I have time.
KeePass 2.09 will also use file transactions for configuration files.
I had been using 2.19 until recently. My database file got corrupted to 6846 NULs. I had not disabled the default "Use file transactions for writing databases" setting. I was sad.
Yes, I run daily backups, but I lost confidence in KeyPass for my sole password store since I lost -and it seems very probable that I will lose again in the future- randomly-generated passwords corrupted between creation and nightly backup.
Theoretically, that setting should have prevented the loss. Theoretically, the interplay was more complex because I sometimes accessed the database file over a share on my Windows 7 network. Theoretically, saving to a uniquely named temporary file before performing the rename would prevent the network share corruption problem. (I'd suggest the name comprise a hash of the stream to be written.)
An additional check, whether or not the way transactions themselves are effected is modified, would be to read the temp file after saving it to verify that the written filestream equals the stream which was to have been written. This check might be performed both after saving and before exiting, and if failed, the program either try again a few times or then at least present a modal alert or dialog.
Is my understanding sound?
Thanks for this program!
If the corruption is caused by Windows shutting down then KeePass cannot prevent this problem - it needs time to complete the save / check and if Windows doesn't allow that time…..
You could set up a trigger to save and backup the database after every update, in case you forget to do it.