#174 Describe Modification(s) in Save Before Close? Window

Jim R

When the user exits KeePass, they may be presented with
the 'Save Before Close?' window if they have not
already saved their edits. The 'Save Before Close?'
window says, "The current file has been modified. Do
you want to save the changes before closing?"

Because KeePass keeps track of the last time an entry
in the database was accessed, through the Last Access
field, and tracks that as a modification, it isn't
known for sure if the prompt to save the file is caused
by modifications manually performed by the user, or if
it is because KeePass wants to save the file to update
a Last Access field.

It would be good for the user to know exactly what has
been 'modified', so that the database is not
inadvertantly overwritten with undersirable data when
the user thinks the database is being saved only for
Last Access time updates.

Internally, it appears that KeePass keeps a
modification flag (indicator) that is set anytime the
contents of the database are edited by the user (as
updated in the Last Modified field) or a field is
accessed (updated in the Last Accessed field) [with the
later operation be altered by the status of the new
Option -> Files, Mark database as modified on
last-access time change].

I would like to suggest that these two database
modifications be tracked separately using two flags
(for example):
- an LA flag - for update of the Last Access field.
- an LM flag - for user edits made to the database.

The OR logic combination of these can then be used to
determine when a file should be saved.

The prompt given to the user in the Save Before Close?
window could then be updated to inform the user of
exactly what will be saved upon exit, for example:

1) LA flag set: "Last Access Time(s) Updated."
2) LM flag set: "Data Modifications Have Occured."
3) LA and LM flags set: "Last Access Time(s) and Data
Modifications Have Occured."

This way, upon exit, the user would have a chance to
understand what will be updated in the database, and if
they did not want to save their edits, they could not
save the file.

The above is the simplest change, that I think could be
done within the existing program structure.

To expand on this idea, something that I think could be
done ... but would require some changes/updates to how
the code saves the database ... it may have to save the
file in two passes. But, just for completness I'll
share some additional ideas:

Given the above example, if they cancel the file saving
to loose their edits, this may cause them to loose the
updates to the Last Accessed field. For some, this
might not be desirable ... they might want to keep the
Last Access times.

So, another option may be to make the saving upon exit
a two-pass process. First, prompt the user to save
their edits, then prompt them to save the updated Last
Accessed field.

If the steps are separated, program options could also
be added for both of these, under Options -> Start and

Automatically save database on exit

with two entries:
Automatically save Last Access time updates upon exit.
Automatically save user edits upon exit.

Obviously, this could create situations where only
parts of the edits are saved. This would add
significant burden to the program to keep track of
edits made in the database separately, and save them
separately. For the momment, I am not suggesting
anything like this, just adding it for ideas.

If the Save Before Close? window could be updated with
more information, I think that would be the greatest
improvement to communicating to the user.

Thanks as always for considering our suggestions.


Log in to post a comment.