-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Detect database file changes using hash #3612
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some comments, mainly reviewed the CLI changes
9258073
to
b8ecef7
Compare
Changes made and fixed tests |
b8ecef7
to
06bc90b
Compare
@phoerious this is ready for your review |
06bc90b
to
52058d9
Compare
Changes made, I recommend a merge commit for this one since a lot of fundamental code was changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If all three commits compile separately, you can simply to a rebase merge. Otherwise squash them.
I will verify but pretty sure they do. |
52058d9
to
d216043
Compare
* Make a clear distinction between saving to the existing file path and saving to a new file path * Use proper save function calls in CLI
* 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.
d216043
to
1cc371f
Compare
That's a great improvement ! Thank you for your work. As the new release isn't published yet, I don't really want to open a new issue. Just to point out an unexpected behavior with this feature. Expected BehaviorUser A and User B are simultaneously using the same keepass file. User A is editing the new entry E1. At the same time, User B is editing a new entry E2. User A is the first to validate his entry E1 while User B is still editing E2. Database is updated. Then User B validates his entry E2. Database is updated. Both users see E1 and E2 in the database. Current BehaviorUser A is editing the new entry E1. At the same time, User B is adding a new entry E2. User A is the first to validate his entry E1 while User B is still editing E2. Database is updated. Then User B validates his entry E2. Database is NOT updated. Finally, only E1 was added to the database and E2 is lost. Debug InfoKeePassXC - Version 2.5.0-snapshot Qt 5.11.3 Operating system: Debian GNU/Linux 10 (buster) Enabled extensions:
Cryptographic libraries: |
This scenario would occur without this change. Please open a new issue for this and a more refined sequence of events please. |
Type of change
Description and Context
Cleanup Database Save Functions
Move FileWatcher into database class
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.
Improve database and CLI tests
Testing strategy
Tested manually and improved test cases.
Checklist:
-DWITH_ASAN=ON
. [REQUIRED]