-
Notifications
You must be signed in to change notification settings - Fork 11
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
Database did not Auto Sync the last time changes were saved, because the KeePass auto-lock operation which saved the changes also closed the database. #45
Comments
Hello, thanks for your report. So, it seems you are having some trouble with KP auto-lock and the plugin's Auto-Sync. There are significant issues when these are used in tandem. When users configure Auto-Sync in the plugin, there is an expectation that it should synchronize the database with the copy on Drive each time the database is saved to the local file. When there are unsaved database changes and auto-lock is engaged, the auto-lock operation can (optionally) save the changes before closing the database. However, the plugin cannot reliably Sync those changes with Drive, because it must operate asynchronously. This means that KP can close the database before the plugin can complete the Sync. There is only time for the plugin to mark the database (with the "flag") indicating that a local Save operation could not be followed by a plugin Sync operation. Note that when such a sequence occurs, the database is truly out of sync with the Drive copy. So, when you return from the auto-lock state, and the database is reopened, the plugin sees the flag and issues the warning message dialog. If you refuse the offer to sync by clicking No, you are deferring the Auto-Sync operation (again), so the flag stays in place (note, the local file and the Drive file remain out of sync, as far as the plugin knows). Currently the only operations that clear the flag are 1) a successful deferred Sync with the plugin, or 2) disabling the Auto-Sync option. A successful sync can occur by either 1) manually invoking Sync on the menu (or on the dialog), 2) manually saving changes to the database by means other than auto-lock, or 3) enabling the Resume on return from Auto-Lock or Exit option. Please correct me if I am wrong, but I think you are suggesting that clicking No on the dialog should result in a one-time breakage of the Auto-Sync contract, and simply clear the flag. Ignoring an "out-of-sync" state the flag represents doesn't sound advisable to me, but perhaps a third Cancel button could be added to the dialog if we really need such an option. I would really like to hear others thoughts about this. If you rely on auto-lock/auto-exit as a primary means to save database changes, you might also consider enabling Auto-Sync's Resume on return from Auto-Lock or Exit option, which will perform the deferred sync without the dialog intervention. And if you haven't already, please review the updated docs for the Auto-Sync feature, and in particular, the deferred sync section, which details how the plugin behaves in auto-lock scenarios. |
Hello ... what I noticed is that: both a manual synchronization, an automatic synchronization, and a synchronization in opening or saving the db do not reset the state of the synchronization flag of the local db with the one on GDrive. |
Thanks for the follow up, and apologies for this late response. In answer to your question: "yes", the plugin supports the Shift key feature of Google Sync 3.x (however, thank you! for revealing the omission of this feature in the documentation). In fact, all KP "open file" events are influenced by this feature, but only when KP has UI focus. This includes re-opening the database upon return from KP auto sync/exit. To this point, you have described KP/plugin behavior that has not been reported elsewhere, and cannot be replicated by developers. Could you please provide more details about your current KP config? Apologies for the inconvenience, but please provide, in full keystroke and mouse-click detail, the steps you take to arrive at the anomalous state? Also, further details of your KP configuration could be helpful:
|
Also, it would also be good for folks effected by issue #36 to weigh in on this issue, as this was the impetus for the "bugfix". |
Hi...
Since my db closed without saving updates, the following message appears and I can't disable it in any way:
This only happens after updating to v4.0.7-beta (by downgrading to v4.0.6-beta, the message no longer appears).
To reproduce the scenario you need to make a change to a value, wait for KP to auto-lock (eg time out or lock workstation) and start working again. If you choose not to save the db and continue working, the following times the message is always repeated and it does not disappear in any way, neither by aligning the local database with GDrive (automatically or manually), nor by ignoring it.
Once that message appears, if I download that db from GDrive to another location, it will also appear here, without the possibility of being removed.
I expect that, once the local db is realigned with the copy on GDrive, that message will never reappear, instead, there is probably a flag that is not updated and the message recurs forever.
Regards,
TJL73
The text was updated successfully, but these errors were encountered: