#1854 Report synchronized entries when sync with external file

KeePass
open
None
5
2015-06-30
2014-04-17
No

Hi, would like to get a logfile when synchronizing with an external file to know which passwords have been updated in the main file... Thanks!

Related

Feature Requests: #1854

Discussion

  • Ulrich Windl

    Ulrich Windl - 2015-06-26

    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?

     
  • wellread1

    wellread1 - 2015-06-26

    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
  • Paul

    Paul - 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

     
  • Ulrich Windl

    Ulrich Windl - 2015-06-29

    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).

     
  • Paul

    Paul - 2015-06-29

    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

     
  • wellread1

    wellread1 - 2015-06-29

    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
    • Ulrich Windl

      Ulrich Windl - 2015-06-30

      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.

       
  • Paul

    Paul - 2015-06-30

    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

     
  • wellread1

    wellread1 - 2015-06-30

    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.

    You should read the Synchronization documentation.

    1. 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.
    2. 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).
    3. 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.
    4. 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

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks