Skip to content
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

Closed
archont00 opened this issue Jan 16, 2017 · 2 comments
Closed

File locking feature is problematic #169

archont00 opened this issue Jan 16, 2017 · 2 comments
Assignees
Milestone

Comments

@archont00
Copy link

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

  • KeePassXC version/commit used: 2.0.3
  • Operating System and version: Archlinux.
@phoerious
Copy link
Member

phoerious commented Jan 16, 2017

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.

@phoerious phoerious added the task label Jan 16, 2017
@phoerious phoerious added this to the v2.2.0 milestone Jan 16, 2017
@phoerious phoerious self-assigned this Jan 16, 2017
phoerious added a commit that referenced this issue Jan 17, 2017
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.
@phoerious
Copy link
Member

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.

phoerious added a commit that referenced this issue Jan 23, 2017
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.
droidmonkey added a commit that referenced this issue Jan 25, 2017
Implement clean shutdown after receiving Unix signals, resolves #169
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants