#2388 2.58 - Problem with "Field References" when the referenced entry is deleted

[Willy Tenner]

Hello!

I ran into a problem today that can be really painful. I use "Field References" a lot, especially on sites that have multiple authentication pages and make use of single sign-on. And so that the URLs are all different, but the credentials are all the same.

Some time ago (probably weeks ago), I deleted an entry (Entry) that I apparently no longer needed (after all, it goes in the trash) without giving it a second thought. What I didn't know was that several other entries refer to the username/password of the entry that was moved to the trash. Everything is still working!

Yesterday I "cleaned up" and finally emptied the contents of the trash. There is no warning. But I was amazed when the reference text appeared when I pasted the username/password and, understandably, the reference could no longer be resolved.

Very stupid! Next problem: I tried to restore the deleted entry from a backup file as follows:

1. in the backupfile.kdbx, moved the said entry from the recycle bin to the root group, i.e. right to the top.
2. delete all entries except the one entry that is to be restored and empty the recycle bin.

3. try to import the backupfile.kdbx using the following "import methods":
   Create new IDs: This works, the entry is imported, but then has a different UUID and all entries that referenced the entry have to be revised. Unattractive.
   Keep existing: I understood that entries that are newly imported are added unchanged, i.e. with their original UUID. Result: The entry is not imported at all.
   Overwrite existing: I have also tried this, but it does not work either.

4. the faster way to insert an entry from another .KDBX file is of course via Entry|Data Exchange. However, this also generates a new UUID.

That's my description for now.

Idea: Each entry carries a "Field Reference Counter" for each field, which increases or decreases by 1 whenever other entries reference the respective field or remove the reference again. When (finally) deleting the reference entry, you should check whether the reference counters are all zero. The "Password Counter" plugin is already available for monitoring password references only.

Question: Have I used or understood importing incorrectly? How can I import/insert an entry from another .KDBX file without generating a new UUID?

Kind regards,
Willy

[wellread1]

The described behavior is not a bug. Permanently deleting an entry that other entries link to via field references breaks the link to the data contained in the deleted entry. This behavior is expected.

The Keep existing and Overwrite existing import will preserve the the UUID of an imported entry. Any entries linked to an imported entry via UUID based field references will be restored provided that:

1. The import succeed and
2. The correct entry was imported and
3. The linked field references are UUID based and
4. The UUID specified in the field references of the dependent entries match the UUID of the imported entry.

It is a straightforward matter to verify that all of the above criteria were satisfied by the import operation.

Field References tend to be brittle for the reasons you mention. Hence, they should be used sparingly and only when there are not other alternatives. The proposed feature request would add overhead to every operation that might affect a field reference anywhere in the database. I doubt that this would be implemented since, for most situations, good alternatives to field references are available..

Two easy ways to protect yourself from accidentally deleting a primary entry:

1. Color primary entries having linked entries: right-click on the entry, select Edit Entry (Quick)>Color. The distinctive background color of the primary entries should be sufficient to alert you that the entry should not be deleted until all dependent field references in other entries are removed/updated.
2. Add a suffix or prefix to all primary entries, e.g. - Primary Entry or - PE to serve as an alert. This method has the added advantage that the prefix/suffix can be searched to find all primary entries in the database. Tags can also be used for this purpose.

[wellread1]

The fact that the developer didn't summarily close this report made me re-evaluate.

I realized the failure to restore the primary entry when using the Keep existing and Overwrite existing occurred because the most recent change to the primary entry was its recent permanent deletion. Since the primary entry in the current database no longer exists and its deleted date, saved in the current database, is newer than the last modified date of the same entry in the backup database, none of the the import options that preserve the UUID of the primary entry will successfully import the deleted primary entry.

The most straightforward workaround is to make a copy of the backup database. Then make a trivial modification to primary entry in the backup database copy, e.g. add a dummy string field to it. Then import the backup database copy into the current database using Overwrite if newer option.

A Restore deleted entry(s) option would be a bit messy to implement since I can imagine a number of criteria that could be useful for restoring select deleted entries. One might match the deleted objects of the current database against the existing entries in the import database, then present a dialog of all restoration candidate entries perhaps with some filtering capabilities. However, this could also become quite unwieldy for larger databases.

[Dominik Reichl]

You might be interested in the ReferenceCheck plugin:
https://keepass.info/plugins.html#refcheck

Before the import, you could alternatively clear the deleted objects information (via the main menu 'Tools' → 'Database Tools' → 'Database Maintenance'). However, this affects all deleted entries, not just the one in question, thus I'd recommend wellread1's approach instead.

Best regards,
Dominik