severe bug is closed without explanation and without fixing? how to proceed?

[sena73]

Hi all

I reported issue #7896 that leads to data loss in Apr 14, 2022. Issue was closed without explanation after 2 years. I checked it few days ago with the 2.7.9 and can confirm that bug is still there.

From my point of view this bug is severe, because it leads to data loss without any error message and is 100% reproducible. Because of that we have to use keepass that works perfectly under the same conditions, without data losses.

So, how to proceed? Should I open a new issue or should I keep reporting into the closed issue? I am sort of lost, as I would expect another attitude.

If that issue is not going to be fixed, I would recommend at least mention about its existence and recommend to use keepass for the similar setup (shared file on samba share).

[droidmonkey]

You haven't given a way to reproduce the behavior you observed. Adding a bunch of groups and entries in the the hopes of replicating something isn't sufficient. Unfortunately, my best advice for you in your scenario is to keep using Keepass2 if it works. It is impossible for us to exactly replicate your environment and sequencing.

1. How many users are sharing the same kdbx file?
2. Can you narrow the issue down to a minimal set of exact steps that are "100% reproducible"?
3. Are both users adding information to the database at the same exact time?
4. Do you leave the entry edit window open for a while? That is a known issue with merging: Database file refresh doesn't occur when entry or group is being edited #8545

[sena73]

1. How many users are sharing the same kdbx file?

Two users are enough to reproduce the bug

Can you narrow the issue down to a minimal set of exact steps that are "100% reproducible"?

May be important: everything happens in Linux.

1. Place kbdx file with single group "test" on the samba share (probably on same machine on same partition will happen too, but i did not test it)
2. Two users open the same file at the same time (+- 3-5 seconds) and start adding subgroups to the group "test" and entries in a following way:

User1:

• open group "test" and add subgroup "s10" (full path /test/s10)
• add password entry pwentry to "s10" (full path /test/s10/pwentry)
• add subgroup "s11" (full path /test/s11), add password entry pwentry to "s11" (full path /test/s11/pwentry)
• add subgroup "s12" (full path /test/s12), add password entry pwentry to "s12" (full path /test/s12/pwentry)
• ...
• add subgroup "s19" (full path /test/s19), add password entry pwentry to "s19" (full path /test/s19/pwentry)

At the same time (may be +- 3 seconds) User2:

• open group "test" and add subgroup "s20" (full path /test/s20)
• add password entry pwentry to "s20" (full path /test/s20/pwentry)
• add subgroup "s21" (full path /test/s21), add password entry pwentry to "s21" (full path /test/s21/pwentry)
• add subgroup "s22" (full path /test/s22), add password entry pwentry to "s22" (full path /test/s22/pwentry)
• ...
• add subgroup "s29" (full path /test/s29), add password entry pwentry to "s29" (full path /test/s29/pwentry)

From time to time users are asked to merge the file - that is expected.

But at the end I always get 2-3 added subgroups lost together with the pwentry! For example, groups "s16", "s17", "s18".

3. Are both users adding information to the database at the same exact time?

They must not hit the button or mouse at exactly same milliseconds, several seconds between creation of s11 and s21 are ok.

4. Do you leave the entry edit window open for a while? That is a known issue with merging: Database file refresh doesn't occur when entry or group is being edited #8545

At which moment edit window has to stay open? Just want to say, there is no editing involved, just adding. After adding all 10 entries one can wait as much as he wants - nothing happens. But I would tell, my issue seems to be related to #8545, it also has to do with simultaneous access to the file. Do not know if another one is 100% reproducible, but I can reproduce my issue 100% times I try it over years and various versions of keepassxc

my best advice for you in your scenario is to keep using Keepass2 if it works

Yes, keepass2 works in the same scenario! We have to stick to it because of that issue, although I like keepassxc more, because it uses C++/Qt, has prettier iface and other features. That problem is the only stopper for us to switch to it.

I still believe it makes sense to mention that issue in FAQ or in documentation, since users do not expect data loss in a tool which tries to implement similar (or better) functionality as in keepass2.

[droidmonkey]

Awesome thank you, I'll try right replicate and narrow the cause. Editing and adding are the same thing when it comes to the bug I linked, so that could definitely be the source of this issue.

[droidmonkey]

I cannot replicate the data loss at all on my own. Tried your exact steps using a SMB share between a Windows PC and a Virtual Linux machine. Worked very well and to expectations.

[sena73]

I cannot replicate the data loss at all on my own. Tried your exact steps using a SMB share between a Windows PC and a Virtual Linux machine. Worked very well and to expectations.

I can create video with the whole process if it helps. Does it make sense?

[droidmonkey]

This is almost surely #8545. You can record the video though to confirm