Keepassxc: Lockfile remains after database auto-locks

[jcharaoui]

Expected Behavior

The database lockfile should be removed when the database auto-locks, if a timeout is configured.

Current Behavior

The database auto-locks, but the lockfile remains.

Possible Solution

Delete the lockfile when the database is auto-locked, the same way it's deleted when the database is closed.

Steps to Reproduce (for bugs)

1. Configure an auto-lock timeout
2. Open a database
3. Wait for the timeout to trigger auto-locking
4. Verify if the lockfile exists

Context

When a database is accessed by multiple users on a network drive, a frequent problem encountered is users forgetting to close KeePassXC, thus preventing other users from modifying it. This problem could be avoided if all users had an auto-lock timeout configured, and if auto-locking would remove the lockfile, allowing other users to modify the database when it's unused. If a user unlocks a database after being auto-locked, the lockfile would be re-created, unless a new lockfile already exists, in which case the database would be simply re-opened in read-only mode.

Your Environment

KeePassXC 2.2.1 in Windows

[mihaiile]

I can confirm that I am using the same context. network drive and multiple pc's with auto-lock and removal of the lock file when database is locked would solve all those problems.

[phoerious]

I tried to fix this, but came to the conclusion that this problem cannot be solved right now. The code that is responsible for managing the lock file needs some heavy refactoring before this issue here can be addressed without creating an utter mess. I therefore need to postpone this to the next feature release.

[fadorator]

👍

That is exactly what I was looking for since KeePassX 1.x, which did it "right". Version 2.x introduced this new behaviour.

I use a shared database file, which lives in a Seafile folder. My colleague and I always have the problem, that one of us forgets to close KeePass, maybe even before holidays.

I'm really looking forward to a solution to this.

[droidmonkey]

Deferred to 2.3.0 due to refactoring work required.

[droidmonkey]

Will be corrected through #1002 by removing lockfile entirely.