Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could not open the database file while attempting to autoreload #3506

Closed
NicolasGoeddel opened this issue Sep 4, 2019 · 4 comments · Fixed by #3612
Closed

Could not open the database file while attempting to autoreload #3506

NicolasGoeddel opened this issue Sep 4, 2019 · 4 comments · Fixed by #3612

Comments

@NicolasGoeddel
Copy link

I am getting the error "Could not open the new database file while attempting to autoreload." when someone else saves the database and it also is open on my computer.

Background information:
I am using KeepassXC 2.4.3 on an Windows 10 Build 1903 system. The database is located on a mapped network drive hosted on a Ubuntu Samba server, available for me and my colleagues. Most of my colleagues are using the original Keepass2 in the latest version on Windows too. We all have the database open all the day and at some time someone changes and entry, adds one, deletes one or whatever you can imagine.

Then KeepassXC recognizes that something has changed, tries to autoreload but fails with a red message telling me it was not able to open the database. Then after a few seconds the error message disappears. However it still did not reload the database. The changes are not available. I have to close the database and reload it again to see the changes. That is not what I was expecting to happen.

I don't want to establish KeepassXC while uninstalling Keepass2 on all computers until I have worked with it a little while. I mostly want to use it because of the better integration in Firefox and Chrome.

Expected Behavior

If KeepassXC is telling me that it is not able to open the database while attempting to autoreload I expect it to try it a few more times instead of just hide the error after a few seconds and pretend that nothing did happen.

Current Behavior

When someone else changes the database I get an error that the database can not be opened. After a few seconds the error disappears and I don't get the changes.

Steps to Reproduce

  1. Install Keepass2 on one Windows PC.
  2. Create a database on a mapped network drive.
  3. Install KeepassXC on an other computer.
  4. Open the database on both of them.
  5. Change an entry with Keepass2 and save.
  6. KeepassXC should show the error, hide it again and do nothing more.

Context

See above.

Debug Info

KeePassXC - 2.4.3
Revision: 5d6ef0c

Libraries:

  • libgcrypt 1.8.4

Operating system: Windows 10 (10.0)
CPU architecture: x86_64
Kernel: winnt 10.0.18362

Enabled extensions:

  • Auto-Tyoe
  • Browser Integration
  • SSH Agent
  • KeeShare (signed and unsiged sharing)
  • YubiKey
@droidmonkey
Copy link
Member

droidmonkey commented Sep 4, 2019

How are you mounting the Samba share in Windows? This could be an authentication thing where it needs to be refreshed.

@NicolasGoeddel
Copy link
Author

I do it like this: https://support.microsoft.com/en-us/help/4026635/windows-map-a-network-drive
The mapped network drive is our main storage for all the people working here. Every software can work with it flawlessly. We are working with MS Office, LibreOfice, Adobe CC and a much more.

Should KeepassXC be fully compatible with Keepass2? Could this be the problem? Or do you think it really has to do with the network drive?

@droidmonkey
Copy link
Member

Just gathering more information. The fact that it is triggering the reload but then cannot open the database is very strange

@NicolasGoeddel
Copy link
Author

Of course. Just tell me if you need to know more. Are there more debugging information available from within the application?

droidmonkey added a commit that referenced this issue Oct 10, 2019
* Fix #3506
* Fix #2389
* Fix #2536
* Fix #2230

Every database that has been opened now watch's it's own file. This allows the database class to manage file changes and detect fail conditions during saving. Additionally, all stakeholders of the database can listen for the database file changed notification and respond accordingly.

Performed significant cleanup of the autoreload code within DatabaseWidget. Fixed several issues with handling changes due to merging, not merging, and other scenarios while reloading.

Prevent database saves to the same file if there are changes on disk that have not been merged with the open database.
droidmonkey added a commit that referenced this issue Oct 14, 2019
* Fix #3506
* Fix #2389
* Fix #2536
* Fix #2230

Every database that has been opened now watch's it's own file. This allows the database class to manage file changes and detect fail conditions during saving. Additionally, all stakeholders of the database can listen for the database file changed notification and respond accordingly.

Performed significant cleanup of the autoreload code within DatabaseWidget. Fixed several issues with handling changes due to merging, not merging, and other scenarios while reloading.

Prevent database saves to the same file if there are changes on disk that have not been merged with the open database.
droidmonkey added a commit that referenced this issue Oct 20, 2019
* Fix #3506
* Fix #2389
* Fix #2536
* Fix #2230

Every database that has been opened now watch's it's own file. This allows the database class to manage file changes and detect fail conditions during saving. Additionally, all stakeholders of the database can listen for the database file changed notification and respond accordingly.

Performed significant cleanup of the autoreload code within DatabaseWidget. Fixed several issues with handling changes due to merging, not merging, and other scenarios while reloading.

Prevent database saves to the same file if there are changes on disk that have not been merged with the open database.
droidmonkey added a commit that referenced this issue Oct 20, 2019
* Fix #3506
* Fix #2389
* Fix #2536
* Fix #2230

Every database that has been opened now watch's it's own file. This allows the database class to manage file changes and detect fail conditions during saving. Additionally, all stakeholders of the database can listen for the database file changed notification and respond accordingly.

Performed significant cleanup of the autoreload code within DatabaseWidget. Fixed several issues with handling changes due to merging, not merging, and other scenarios while reloading.

Prevent database saves to the same file if there are changes on disk that have not been merged with the open database.
droidmonkey added a commit that referenced this issue Oct 20, 2019
* Fix #3506
* Fix #2389
* Fix #2536
* Fix #2230

Every database that has been opened now watch's it's own file. This allows the database class to manage file changes and detect fail conditions during saving. Additionally, all stakeholders of the database can listen for the database file changed notification and respond accordingly.

Performed significant cleanup of the autoreload code within DatabaseWidget. Fixed several issues with handling changes due to merging, not merging, and other scenarios while reloading.

Prevent database saves to the same file if there are changes on disk that have not been merged with the open database.
scoroi pushed a commit to scoroi/keepassxc that referenced this issue Nov 10, 2019
* Fix keepassxreboot#3506
* Fix keepassxreboot#2389
* Fix keepassxreboot#2536
* Fix keepassxreboot#2230

Every database that has been opened now watch's it's own file. This allows the database class to manage file changes and detect fail conditions during saving. Additionally, all stakeholders of the database can listen for the database file changed notification and respond accordingly.

Performed significant cleanup of the autoreload code within DatabaseWidget. Fixed several issues with handling changes due to merging, not merging, and other scenarios while reloading.

Prevent database saves to the same file if there are changes on disk that have not been merged with the open database.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants