-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
File locking feature is problematic #169
Comments
Having two instances of KeePassXC running which both write to the same file is generally unsafe and may lead to corruption. More to your point: a stale lock file should not cause any problems since it will get deleted if the process which wrote that lock file doesn't exist anymore. It should therefore never block KeePassXC from reopening a database after a fresh login. If you are really having problems with stale lock files, though, please try out the most recent KeePassXC version from the develop branch (install keepassxc-git from AUR) and make sure you are also using a recent Qt version (preferably 5.7). I just verified that stale lock files get silently replaced when reopening the database. However, I agree that lock files should be removed when KeePassXC receives a SIGINT to prevent cluttering the file system with hidden lock files. |
The database wasn't saved properly and lockfiles were not removed when receiving the signals SIGINT, SIGTERM, SIGQUIT or SIGHUP. This patch implements signal handling and performs a clean shutdown after receiving SIGINT SIGTERM or SIGQUIT and ignores SIGHUP. Since this uses POSIX syscalls for signal and socket handling, there is no Windows implementation at the moment.
Since there hasn't been any response from you, I assume that your issue was resolved and I will close this. If you are still encountering issues, please start a fresh issue report. |
The database wasn't saved properly and lockfiles were not removed when receiving the signals SIGINT, SIGTERM, SIGQUIT or SIGHUP. This patch implements signal handling and performs a clean shutdown after receiving SIGINT SIGTERM or SIGQUIT and ignores SIGHUP. Since this uses POSIX syscalls for signal and socket handling, there is no Windows implementation at the moment.
Implement clean shutdown after receiving Unix signals, resolves #169
When I shutdown computer (Arch Linux, Mate) without exiting KeePassXC manually, the .db-name.lock file remains in the folder and blocks KeePassXC from opening the db file next login (it is automatically started on logon). Even when confirming "yes, open the file anyway", the original lock file remains in the folder and the user has to delete it manually (in terminal, since it is a "hidden" file, which are usually not displayed in the file managers by default).
Expected Behavior
KeePassXC should avoid using lock file on db.
Current Behavior
On force close, the lock file remains stale. It does not get deleted even on forced re-opening by user.
Possible Solution
Instead, it should read the db before save and merge any changes. (The same way as Keepass2Android does it.) It would also resolve a problem of file syncing in the background (e.g. via Dropbox) with other clients/systems.
Your Environment
The text was updated successfully, but these errors were encountered: