I'd also vote for having a (optional) log for sync: At the moment sync is absolutely silent, and it saves both databases. So if something really went wrong, it may be too late when you realize that days later.
While the user can play with triggers, it's more a work-around rather than a solution.
Maybe as we have a "history" per entry already, why not have a "sync log" per database?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What additional information would you like to see logged or viewable?
The Last Modification Time of an entry is already logged. It is possible to review all entries sorted by this field immediately after syncing as follows: check the Last Modification Time in 'View>Configure Columns...'; then display all entries by setting 'Edit>Show All Entries' and 'View>Grouping in Entry List>OFF'; finally sort all entries by Last Modification Time in the Entry List pane.
A KeePass password database is a file that can be copied. Initially identical copies of the same database can't easily be uniquely identified. So while I am not a programmer, I don't see how the synchronization history of an entry can be tracked; e.g. which particular copy of a database a change was made in. Also KeePass does not include a user concept so it is not possible track changes made by a 'KeePass user'.
Last edit: wellread1 2015-06-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A true log of changes would list the changes explicitly and that is not secure.
If something went wrong to make your entries invalid you would need to either go back to the history or a backup from before the change, but it's more likely that the sort of error causing data corruption would make a mess of the whole database.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A "log of changes" does not need to log the values. E.g. it would be sufficient to say that "field X" of entry "Y" was updated (plus maybe the modification time of the original). I think the fact that a database can be copied is of no significance in this discussion (neither the discussion of whether there are "users").
However it would be helpful (and safe) to restrict the direction of synchronization (Update A from B, where B would never be modified).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The KeePass sync is designed to maintain duplicate copies of the database. One way sync is effectively sync of a subset and this can be done by using multiple databases.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
E.g. it would be sufficient to say that "field X" of entry "Y" was updated (plus maybe the modification time of the original).
The entry data is always edited as a related group of data (i.e. in a modal dialog) and only changes to the group as a whole are tracked (i.e. "field X" of entry "Y" is not tracked). It would require a database format change to include all the flags needed to increase the tracking granularity. While such additional granularity might be convenient in some cases, e.g. tacking the time that changes are made to the username/password field set, I am not sure that the feature is needed so much that it justifies changing the database format.
However it would be helpful (and safe) to restrict the direction of synchronization (Update A from B, where B would never be modified).
That is an entirely different feature request.
A one-way synchronization is the same as a database copy, or an export of a subset of entries. You can already do that.
If you wished for a more nuanced "one-way" synchronization (e.g. Master-Slave databases with one-way or two-way synchronization of subsets of entries in the Master) that is much, much more complicated. As Paul points out it is possible to manage individual sets of entries separately using multiple databases.
KeePass synchronization is designed to make the entries of two databases identical.
Last edit: wellread1 2015-06-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even if entries are compared as a whole, there is no reason why changes cannot be isolated to single fields: You'd use a compare function to find the changes. You don't need a new database format for that.
When restricting the direction of synchronization (for A to B), it's more a safety measure (against user confusion and programming errors) rather than a new feature request. And a one-way synchronization is not a database copy; if it were, you would not need a synchronization function, because then sync (A, B) would be identical to copy A to B first, and then copy B to A. Obviously this is not the case!
If you sync A to B, everything present in A and not in B would be created in B, and everything in A newer than in B would be updated in B. A would be unchanged. It seems the concept of synchronization has different meaning to different people.
And also, one-way synchronization is NOT "much much more complicated" (than bi-directional synchronization); it's actually easier. (Before it was said on-way synchronization were equivalent to database copy, which also is not true, but would contradict the next statement). Eventually what makes the difference of "sync A to B, then sync B to A" versus "sync A and B" is when individual fields of a corresponding entry of A and B differ (one filed updated in A's entry, and another field updated in B's entry). It was stated that that case isn't handled, so actually the directional sync must be there already.
If "KeePass synchronization is designed to make the entries of two databases identical", you could just copy the databases. Obviously you missed one essential feature of synchronization, namely replacing obsolete data with current data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even if entries are compared as a whole, there is no reason why changes cannot be isolated to single fields: You'd use a compare function to find the changes. You don't need a new database format for that.
That is an excellent observation that I had missed. Something like that probably could be implemented as a plugin. Perhaps someone will do it. From the perspective of a password manager, I don't perceive a large value for generalized display of when the "field X" of entry "Y" was updated, however being able to tease out when an entry's username and/or password was last changed would be useful.
And a one-way synchronization is not a database copy; if it were, you would not need a synchronization function, because then sync (A, B) would be identical to copy A to B first, and then copy B to A. Obviously this is not the case! It seems the concept of synchronization has different meaning to different people.
I don't understand the italicized portion of the statement above. (However, It may not be relevant to the discussion below.)
If you sync A to B, everything present in A and not in B would be created in B, and everything in A newer than in B would be updated in B. A would be unchanged. It seems the concept of synchronization has different meaning to different people.
In other words, 'B' becomes identical to 'A' unless 'B' contains entries that never existed in 'A'. However your previous framing of one-way synchronization disallowed that: "Update A from B, where B would never be modified". If 'B' is never modified by the user, it can not contain entries that don't exist first in 'A'; or perhaps I misunderstood your meaning?
If editing of 'B' is allowed, then 'A' becomes out-of-date because it is never updated by 'B'. However, rigorously disallowing editing of 'B' is not easy or difficult, it is impossible.
.... It was stated that that case isn't handled, so actually the directional sync must be there already.
KeePass uses one-way synchronization (directional synchronization) for Database Settings. For most other objects it uses 2 way synchronization. There is a table of synchronization behavior for most objects in bug report 1261. It is slightly out-of-date, but if you read the developer's comments following that post, you can deduce the current behavior.
And also, one-way synchronization is NOT "much much more complicated"
I agree one-way synchronization as you have described is not much more complicated, it is deeply flawed.
Master-Slave synchronization is much more complicated.
If "KeePass synchronization is designed to make the entries of two databases identical", you could just copy the databases. Obviously you missed one essential feature of synchronization, namely replacing obsolete data with current data.
A copy of A does not make it identical to B. The copy is identical to A. However, if changes are only allowed in A, then A is the authoritative copy and B can be discarded.
The problem with one-way directional-only sync is that it makes all entries in B that exist in A, identical to A by overwriting the corresponding entry in B regardless of time-stamp (i.e. A is copied onto B; the History is also overwritten or it becomes inconsistent).
The problem with one-way time-stamped sync is that A is never updated, as a result it becomes out-of-date. As mentioned above, forbidding editing of B is impossible.
Only a two-way, time-stamp based synchronization can make both A and B identical while preserving independent changes made to entries in either A or B.
Last edit: wellread1 2015-06-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can use or adapt the audit trigger for this.
Great! This definitely does the trick! Thanks a lot for the info!
Cordialement / Best Regards,
Jean-Luc GARNIER
Pour accéder à mes coordonnées complètes http://www.jeanlucgarnier.tel/,
abonnez vous sur TelFriends http://lnkd.in/uUvGif !
2014-04-17 20:23 GMT+02:00 wellread1 wellread1@users.sf.net:
Related
Feature Requests:
#1854I'd also vote for having a (optional) log for sync: At the moment sync is absolutely silent, and it saves both databases. So if something really went wrong, it may be too late when you realize that days later.
While the user can play with triggers, it's more a work-around rather than a solution.
Maybe as we have a "history" per entry already, why not have a "sync log" per database?
What additional information would you like to see logged or viewable?
The Last Modification Time of an entry is already logged. It is possible to review all entries sorted by this field immediately after syncing as follows: check the Last Modification Time in 'View>Configure Columns...'; then display all entries by setting 'Edit>Show All Entries' and 'View>Grouping in Entry List>OFF'; finally sort all entries by Last Modification Time in the Entry List pane.
A KeePass password database is a file that can be copied. Initially identical copies of the same database can't easily be uniquely identified. So while I am not a programmer, I don't see how the synchronization history of an entry can be tracked; e.g. which particular copy of a database a change was made in. Also KeePass does not include a user concept so it is not possible track changes made by a 'KeePass user'.
Last edit: wellread1 2015-06-26
A true log of changes would list the changes explicitly and that is not secure.
If something went wrong to make your entries invalid you would need to either go back to the history or a backup from before the change, but it's more likely that the sort of error causing data corruption would make a mess of the whole database.
cheers, Paul
A "log of changes" does not need to log the values. E.g. it would be sufficient to say that "field X" of entry "Y" was updated (plus maybe the modification time of the original). I think the fact that a database can be copied is of no significance in this discussion (neither the discussion of whether there are "users").
However it would be helpful (and safe) to restrict the direction of synchronization (Update A from B, where B would never be modified).
The KeePass sync is designed to maintain duplicate copies of the database. One way sync is effectively sync of a subset and this can be done by using multiple databases.
cheers, Paul
The entry data is always edited as a related group of data (i.e. in a modal dialog) and only changes to the group as a whole are tracked (i.e. "field X" of entry "Y" is not tracked). It would require a database format change to include all the flags needed to increase the tracking granularity. While such additional granularity might be convenient in some cases, e.g. tacking the time that changes are made to the username/password field set, I am not sure that the feature is needed so much that it justifies changing the database format.
That is an entirely different feature request.
A one-way synchronization is the same as a database copy, or an export of a subset of entries. You can already do that.
If you wished for a more nuanced "one-way" synchronization (e.g. Master-Slave databases with one-way or two-way synchronization of subsets of entries in the Master) that is much, much more complicated. As Paul points out it is possible to manage individual sets of entries separately using multiple databases.
KeePass synchronization is designed to make the entries of two databases identical.
Last edit: wellread1 2015-06-29
Even if entries are compared as a whole, there is no reason why changes cannot be isolated to single fields: You'd use a compare function to find the changes. You don't need a new database format for that.
When restricting the direction of synchronization (for A to B), it's more a safety measure (against user confusion and programming errors) rather than a new feature request. And a one-way synchronization is not a database copy; if it were, you would not need a synchronization function, because then sync (A, B) would be identical to copy A to B first, and then copy B to A. Obviously this is not the case!
If you sync A to B, everything present in A and not in B would be created in B, and everything in A newer than in B would be updated in B. A would be unchanged. It seems the concept of synchronization has different meaning to different people.
And also, one-way synchronization is NOT "much much more complicated" (than bi-directional synchronization); it's actually easier. (Before it was said on-way synchronization were equivalent to database copy, which also is not true, but would contradict the next statement). Eventually what makes the difference of "sync A to B, then sync B to A" versus "sync A and B" is when individual fields of a corresponding entry of A and B differ (one filed updated in A's entry, and another field updated in B's entry). It was stated that that case isn't handled, so actually the directional sync must be there already.
If "KeePass synchronization is designed to make the entries of two databases identical", you could just copy the databases. Obviously you missed one essential feature of synchronization, namely replacing obsolete data with current data.
A sync log could be created but to date it hasn't. As there is an alternative I suspect it won't happen.
cheers, Paul
That is an excellent observation that I had missed. Something like that probably could be implemented as a plugin. Perhaps someone will do it. From the perspective of a password manager, I don't perceive a large value for generalized display of when the "field X" of entry "Y" was updated, however being able to tease out when an entry's username and/or password was last changed would be useful.
I don't understand the italicized portion of the statement above. (However, It may not be relevant to the discussion below.)
In other words, 'B' becomes identical to 'A' unless 'B' contains entries that never existed in 'A'. However your previous framing of one-way synchronization disallowed that: "Update A from B, where B would never be modified". If 'B' is never modified by the user, it can not contain entries that don't exist first in 'A'; or perhaps I misunderstood your meaning?
If editing of 'B' is allowed, then 'A' becomes out-of-date because it is never updated by 'B'. However, rigorously disallowing editing of 'B' is not easy or difficult, it is impossible.
KeePass uses one-way synchronization (directional synchronization) for Database Settings. For most other objects it uses 2 way synchronization. There is a table of synchronization behavior for most objects in bug report 1261. It is slightly out-of-date, but if you read the developer's comments following that post, you can deduce the current behavior.
I agree one-way synchronization as you have described is not much more complicated, it is deeply flawed.
Master-Slave synchronization is much more complicated.
You should read the Synchronization documentation.
Last edit: wellread1 2015-06-30
Duplicate of
https://sourceforge.net/p/keepass/feature-requests/1232/