Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1020 3.28 Claims History of Recently Changed Items Corrupted

v1.0_(example)
closed
nobody
None
5
2013-01-09
2012-03-23
Gil
No

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.

Discussion

  • DrK
    DrK
    2012-03-23

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

    David

     
  • 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.

    Thanks

    David

     
  • 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:
    http://pwsafe.org/tmp/pwsafe_rev_4838.zip

    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.

    David

     
  • Rony Shapiro
    Rony Shapiro
    2013-01-09

    • status: pending --> closed
    • milestone: --> v1.0_(example)