Workarounds when facing an issue?

[rhinot]

Hey All,
Been using KeePassXC a long time and love it. I'm currently facing an issue that prevents me from saving, which means KPXC is useless for me for any new accounts/passwords.

I know the Devs have many things to fix, so this may not get fixed right away. Does anyone have any workarounds that I could use to store passwords temporarily that isn't completely unsafe?

[droidmonkey]

Possibly create a new database or change to a different storage method.

[rhinot]

Thanks!

I tried all storage methods. All fail sadly.

Is the idea that I start a new database and store the new passwords until the issue is fixed, or that I could potentially import passwords in from the old database?

[droidmonkey]

It is totally unclear why this issue is happening to a very small set of users, so it is hard to fix it. Any insights into why you have perpetual failures with saving a file? We are not doing anything fancy.

[rhinot]

It could be something about it being a mounted network drive, although this hasn't been an issue in the past - even when the drive went offline. My guess is that some state was set or threshold met within keepass, that's causing this to fail. For example, it could be that the kdbx file reached a certain size and thus a timeout limit is hit. I haven't looked at the code to know what variables are set/monitored on a write. I'm guessing you know well though. :) Are there any similarities between the different users who are experiencing the same issue? Are they all on the same OS? Networked drives? Certain size KDBX files? I'm happy to run a debug build, if you think it would be helpful to understand what's causing this.

…

On Wed, Feb 14, 2024 at 7:56 PM Jonathan White ***@***.***> wrote: It is totally unclear why this issue is happening to a very small set of users, so it is hard to fix it. Any insights into why you have perpetual failures with saving a file? We are not doing anything fancy. — Reply to this email directly, view it on GitHub <#10302 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOARRUYTIJ6V7XMNXTO43DYTVMK5AVCNFSM6AAAAABDG7S6PWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINZTHA2TQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[droidmonkey]

It seems to be generally network drives. Did you change your database encryption settings at all?

Basically, the sequence that causes that error message requires a database to get stuck in a save operation, like an infinite loop. Either saving is taking forever and not timing out, or the key derivation is not completing.

This could also be a deadlock situation where you save and immediately the database is attempting to lock or close which might cause the mutex check to deadlock.

If you enable alternative saving method - direct write save, does this still happen? https://keepassxc.org/docs/KeePassXC_UserGuide#_advanced_save_options

[PredatorIWD]

In regards to mutex and a possible cause of this problem in my case that seemingly randomly stopped happening that I mentioned in the original issue thread, it wasn't a network drive but I did have the database file be inside a folder on the OS drive that was synced with the Dropbox desktop app to the Dropbox servers by me launching that app every few weeks, syncing and then closing it completely, at a similar interval at which this problem was happening.

Looking back at it now, the problem not happening ever again does fit the timeline of around the time when I stopped using Dropbox altogether, especially given the fact that it stopped happening without me changing the KeePassXC version or my hardware/storage setup.

[rhinot]

I didn't, but that's super helpful. I'd think it was the mutex check, but this happened independent of a product update, so I'm guessing this wouldn't just randomly start one day. Is it possible the key was corrupted that prevents saves, but allows opens? If so, is there a way I could check for that?

…

On Wed, Feb 14, 2024 at 11:23 PM Jonathan White ***@***.***> wrote: It seems to be generally network drives. Did you change your database encryption settings at all? Basically, the sequence that causes that error message requires a database to get stuck in a save operation, like an infinite loop. Either saving is taking forever and not timing out, or the key derivation is not completing. This could also be a deadlock situation where you save and immediately the database is attempting to lock or close which might cause the mutex check to deadlock. — Reply to this email directly, view it on GitHub <#10302 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOARRRJT4AJSAZNTL5M37DYTWET3AVCNFSM6AAAAABDG7S6PWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINZUHA3DA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[droidmonkey]

The key is cycled (recreated) on every save, that wouldn't be the cause. This is most likely a file operation gone sideways. Something is causing the file save to enter an infinite timeout.

[rhinot]

I ended up exporting to CSV, then imported to create a new database. Tried that file locally and on the mounted network drive. No issues.

Sounds like it is some type of file-level corruption.

[droidmonkey]

The file is recreated entirely on every save. Perhaps there is an infinite loop happening because of something with your entries, and a save can never finish. In other words, the file itself is not the issue. Something in how we process data in your database is.