Help troubleshooting automatic db changes on unlock/"weird behaviour"

[imsodin]

I know how this sounds, I wouldn't trust this report for a second if I was a maintainer/supporter, so I guess I a mainly asking for troubleshooting hints. E.g. I couldn't figure out any way to get logging in place. Or options I might try toggling to see if it makes a difference.

What's happening:

1. Macos 15, with an old version of my database - very old DB, lots of entries, also sharing involved, ... Keepassxc stopped for good measure.
2. The database file is replaced with a newer version.
3. I open keepassxc and unlock the database.
4. It shows as edited right away (asterisk after the db name in the tab). Turns out it went back to the state of the old version, e.g. confirmed after saving by running keepassxc-cli merge --dry-run with a backup copy.

No matter what I do, this always happened. I changed a bunch of configs, e.g. reload on external change or auto-save, always the same behaviour. And I feel like I am going insane - on one hand it's happening consistently on very simple steps, on the other hand this cannot be a bug, it's way too in your face, it has to be user (that's me) error. I just don't know what to try anymore.

I also looked at ~/Library/Application\ Support/ if there's some state/cache to reset, didn't find anything. And I did copy/rename the database, same behaviour. The file is stored under the home directory, no special filesystem. I do use syncthing to sync it, however I stopped it to make sure it's not related to that.

Any hints much appreciated.

[droidmonkey]

To clarify, you overwrote the original old database with the new database file? And you are for sure opening that specific database file? Sounds a lot like you are actually opening a backup copy.

An older database may show as edited because of some modernization processes that happen to make sure everything works properly.

Also noticed you are a syncthing maintainer, could it be this database is being overwritten by syncthing for some reason during the process of you opening it?

[imsodin]

Also noticed you are a syncthing maintainer, could it be this database is being overwritten by syncthing for some reason during the process of you opening it?

Missed this in the previous reply - as noted before, that was an initial suspicion of mine as well, but unfortunately that's not it:

I do use syncthing to sync it, however I stopped it [syncthing] to make sure it's not related [...].

[droidmonkey]

You mentioned using sharing, I assume keeshare. Could you try disabling keeshare from the application settings and seeing if the file remains current? This may also be why you are getting modified indicator right after opening.

[imsodin]

Bingo! The "Allow import" checkpoint in the KeeShare settings controls the behaviour, it's gone when unchecked.

However none of the entries that get "reverted"/removed are part of the shared group. Any further things I can try out to debug this? E.g. to get any info on what the keeshare thing is doing, and maybe why?

Just for completeness: Before I saw your keeshare suggestion, I also tried to repro with 2.7.9 appimage on linux, and couldn't.

[droidmonkey]

Sharing and merging are actually done at the entry level. The group just defines the settings for sharing and initial shared entries. If you move entries out of the shared group, they are still shared. Importing a share with entries of duplicate uuids will also likewise still be merged regardless of location.

This unique quirk of sharing will be addressed in our 2.8.0 release to make sharing and shared entries strongly bound to a parent group.

You can read more about this in our docs: https://keepassxc.org/docs/KeePassXC_UserGuide#_database_sharing_with_keeshare

[imsodin]

That does sound very plausible, I definitely did do a lot of reshuffling at the time I introduced the sharing. What initially confused me is that it only happens on my macos client, not on linux (neither 2.7.4 nor .9). However one db I share with only exists on the macos device, so maybe some deletions/modifications from previously moved entries can only happen there.

Anyway, good to hear this not entirely self-evident behaviour will be improved in 2.8.0. And having an idea of what's going on, I hopefully can "clean up" my databases to resolve this issue.

Thanks for your kind help! And for maintaining this awesome project!

[droidmonkey]

Welcome and thank you! And yes, my first thought goes to the share files that are causing this issue are not present or reachable on the other platforms.