The same happens when closing the database in Ubuntu using the Window Manager - pressing "x", close window.
PS v1.04 BETA
It seems to me that, if there is an event raised when exiting the app, it could have a handler to orderly close the open databases, and to release the locks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not just upon shutdown that the .plk lock file doesn't get deleted as expected. Here's what I've observed with v3.52.
Before each scenario below:
Passwordsafe is not running
Lock file manually deleted before launching passwordsafe, if it exists..
Launch password safe, open safe, lock file is created.
Test scenarios:
Choose File --> Close, safe is closed and lock file is deleted.
Choose File --> Exit, or Alt+F4, passwordsafe exits, lock file is not deleted
Right-click passwordsafe tray icon, pick Exit, passwordsafe exits, lock file is not deleted
Conclusion: the lock file is not being deleted on a "normal" exit. If this is fixed, it'll probably be fixed for passwordsafe being terminated by a shutdown too.
Last edit: ku-be 2020-07-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should add that I observed this behavior on PS version 3.49.01
The same happens when closing the database in Ubuntu using the Window Manager - pressing "x", close window.
PS v1.04 BETA
It seems to me that, if there is an event raised when exiting the app, it could have a handler to orderly close the open databases, and to release the locks.
It's not just upon shutdown that the .plk lock file doesn't get deleted as expected. Here's what I've observed with v3.52.
Before each scenario below:
Test scenarios:
Conclusion: the lock file is not being deleted on a "normal" exit. If this is fixed, it'll probably be fixed for passwordsafe being terminated by a shutdown too.
Last edit: ku-be 2020-07-11
I was also able to reproduce this using v3.52. It does appear to be a problem that needs fixing.
On further investigation, it appears that this issue started at v3.51 as I could not reproduce it with v3.50 or v3.49.
Hi Rony,
Can this important bug be addressed in v3.53 final?
Per my investigation, it started at v3.51
Regression - fixed in commit ecbf17fcc
Will be in 3.53
Awesome! Thank you!