#1020 3.28 Claims History of Recently Changed Items Corrupted


I have been running 3.28.

I have found that, when I open a database, the application sometimes reports that some entries are corrupted and need to be fixed. The problems reported are with the entries' password history.

When I look at the affected entries, I see that their password histories have been recovered to things that don't make sense (e.g., dates in 1969).

The most recent time this happened, I declined to save the modified database after opening. I immediately quit the application.

Opening the same database with 3.27 reports no problems. If I go to the entry that was reported when I tried to open with 3.28, its password history has no problems.

It is as if 3.28 saves a password history in a corrupted format that it can't read.


  • DrK

    DrK - 2012-03-23

    What happens in V3.27 and you use the Validate command or the validate command line flag?


  • Gil

    Gil - 2012-03-23

    I was trying 3.27.01 (4576+)G.

    Validate from the Manage menu did nothing.

    Opening with -v produced a minidump. (This was a test version that was configured minidumps when it tried to modify entries in some cases.)

    I went all the way back to the released 3.27.

    Manage-Validate still did nothing.

    Opening with -V produced a report that included the entry in question, saying "The following entries had an invalid Password History. This has been rebuilt with available data. There may be some loss of history."

    That said, the history looks OK (unlike the case when 3.28 opened the file).

  • DrK

    DrK - 2012-03-23

    I am not sure this will work (as it might change the password history) but....

    If you can
    1. Reopen that DB with 3.27 but do not validate it.
    2. Save it as another database.
    3. Delete all other entries except this one.
    4. Rename the title and user fields and maybe the URL/email if present but do NOT change the password (hopefully enough has been removed to make it useless to us developers except to reproduce the problem).
    5. Change its master passphrase.
    6. Save it.

    Then see if V3.28 still corrupts the password history.

    If it does and you are happy to send it to us, please send it directly to me via email and also send me the passphrase. I can send it to Rony if he is going to look at it instead of me.



  • DrK

    DrK - 2012-03-24

    Thanks for the database - enabled me to solve the problem quickly. This has been in PWS for years!

    However, the change from user initiated validation (using the '-v' command line flag or Manage->Validate when no database is currently open [which explains why the menu option did not work for you]), which was used rarely, to automatic validation on database open has brought it to the fore.

    It has been fixed at revision 4838. I have uploaded a fixed version to:

    For your particular entry in error, the header said there were 9 (out of a maximum of 10) saved old passwords but there were only 5 there. It rebuilt the history incorrectly.

    I checked with V3.27 and for me the history was incorrect in the same manner as with V3.28. As I said, the 2 versions used the same (incorrect code) and so I expected them to be the same. However, I am surprised that your V3.27 produced a valid history after manual validation.


  • Rony Shapiro

    Rony Shapiro - 2013-01-09
    • status: pending --> closed
    • milestone: --> v1.0_(example)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks