Silent error writing to Database
Popular easy-to-use and secure password manager
Brought to you by:
ronys
Menu
▾
▴
#1006 Silent error writing to Database
I have just updated to v3.27 from v3.23. I have always used a simple CMD script on windows to start PasswordSafe consistently: start ..\bin\ps\pwsafe.exe PWS.psafe3 -u auser -h ahost
In v3.23 all was fine. I could add an entry, quit, restart and the entry was there.
In v3.27, something is broken. I add an entry, it appears to be be saved (you see the telltale pause and flicker), but when I quit and restart the change is NOT there. For my change to work, I have to first explicitly "close" the database, and then reopen it from the "File" menu (either from Open... or from the list of recent databases) and then make the change.
On a likely related note, I had to turn off "Intermediate Backups" in the configuration menu. When it is ON, I get an "Write Error" dialog which says "Unable to create intermediate backup.. Either try to save database with another name or exit without saving." I have never seen this in v3.23 or earlier
I should mention that I am running this on Windows 7 32 bit.
Clarification: I see this as TWO separate bugs:
(1) Writing the database does not work in some cases
(2) The failure is a QUIET error with no notification to the user. I only spotted it when I went back the next day to edit an entry and it was not there. I first questioned my memory, and then tried a test entry...
Do either of the errors (not saving and write error during intermediate backups) occur if you do not add the command line parameters " -u auser -h ahost"?
I don't agree with the save problem being 2 independent issues - I suspect that an underlying issue causes both.
David
It happens even if I remove the user and host command line arguments.
My complaint#2 is related to the fact that I only get NOTIFIED of the write failure when it is trying to do the incremental save, and not when the normal save fails. The correct behavior is to warn me ALWAYS when the write fails.
Since no one else has this issue, I have a strong suspicion that it is due to you executing PasswordSafe from inside a script.
Do either of the errors (not saving and write error during intermediate
backups) occur if you do not use a script?
Are you using the Microsoft suggested method of executing commands from within a script i.e. the start command from and CMD or BAT file (see http://ss64.com/nt/start.html)? The warnings etc. may be intercepted if not invoked in this manner.
David
I have seen this and struggled with it since the beginning. This is a long-standing and disturbing bug and it seems to affect only a few entries. At any time, some entry might disappear and I would have to recover it from a backup.
I should add that I am running this on Windows XP (not from a script), and I have never gotten any sort of intermediate backup problems even though that is enabled.
Two issues:
This could well be a script problem. Although the whole script hasn't been uploaded, I can see from the original snippet the execution seems to be the full path to PasswordSafe program (i.e. ..\bin\ps\pwsafe.exe). If the working directory is not set using the "start" "/D" command line parameter (see http://ss64.com/nt/start.html), then the working directory will be that of the Windows command processor (cmd.exe), which is normally C:\Windows\system32. Even if you run as Administrator, PasswordSafe may not have the authority to update files in this directory.
I don't understand this issue. When a database is saved, all entries in memory (which will be all entries that are displayed in the Tree or List views), are written to disk after the current database file is renamed as per the user's backup preferences. I can't see how any entry would be skipped. If it exists - it is written out.
To help with finding out what may be causing this, when it next happens, when you open the backup file, please would you export the particular entry that was not saved to XML and upload it here - WITH any sensitive information obscured. Also, please note what changes you made to the entry which were then lost somehow.
Thanks
David
That's just the thing. It isn't the entry that I changed that disappears. It's always a particular entry.
Some additional info. I upgraded to 3.27 and then saw the "Validate" menu item. When I ran it on my database, it came back with 2 entries that had invalid UUIDs, one of which was the one that kept on disappearing.
Is there any logging or any way to turn on any sort of debug logging that we could do to help you?
If you still have a backup before you did the Validate, would you mind exporting the 2 entries it later changed to an XML file and, after obscuring any sensitive data, either upload to this Bug Report or email it to me at "c-273 AT users DOT sourceforge DOT net"
Thanks
David
David
Rob,
Did Validate fix your issue?
David
Sorry this took so long to get back on this. I have discovered another data point. When I do a "Compare" of two databases (generally one on my main Windows machine that I have added entries to, against the database on my laptop) for syncronization purposes (yes, there may be other ways to do this, I realize that), I found two issues, the first only allowed me to transfer two entries across ("Copy to original") while ignoring the right click after two entries copied. This is a new issue just encountered.
The main issue is that after I ran the compare again and it let me copy the last entry across, running "Validate" on this latest database showed an invalid UUID for the just copied last entry only. The other two entries that were copied first were ok. I then ran a validate on the original database with no problems found. Looks like there are some issues with copying from database to database, with the UUID being corrupted. As I now remember, the other entry that I found a bogus UUID with was also copied across using this same procedure.
Hope this helps.
Oh, also, the two entries that had bogus/corrupted UUIDs had "0"s in them for a UUID. All other entries in the XML seemed to be correct. I hope this would make my sending you the XML now not necessary.
Please upgrade to the just released V3.28. This release validates all databases at open time unless overridden with a command line flag "--novalidate" (without quotes).
It may have fixed this issue, although no promises as I don't fully understand your issue.
David
I am the original problem person in this thread. I just updated to 3.28 and still have the same problem.
I open the PS (and the DB), and then edit an entry. PS complains that incremental backup has failed (until I turn that off in the preferences), and the write does not happen.
I then close the DB (but leave PS open). I reopen the same (and only) database. At this point I can do edits and saves will happen without a problem.
Did you add the "start" command line flag "/D" as I suggested back in 2011-12-25 15:56:14 PST?
David
Bug report #1063 may help explain why the 'intermediate backups' issue is happening. I just discovered this myself and did some thorough testing and came to a conclusion that when including the safe file (i.e. <file>.psafe3) in the path of the shortcut or command line statement, if you do not include the absolute path, the program doesn't look at the directory in which the psafe3 file came from properly. It will open, but when you go to close the file, since it doesn't include the present directory in which the psafe3 file came from, it can't save back to its original file/location.
Please review the report for more details.