GNOME Bugzilla – Bug 642251
Key-file backend always adds entries upon linking, rather than replacing as necessary
Last modified: 2011-08-01 19:01:45 UTC
If I've got a set of contacts A, B, and C, and link them as such: A <-> B => AB AB <-> C => ABC The key-file backend ends up with entries in relationships.ini like: [0] protocol=A;B; [1] protocol=A;B;C; Obviously, we don't need entry [0] once we've got entry [1]. So, there are two problems here: 1. The key-file backend has some code to eliminate duplicates from the key-file when exposing Personas, but apparently this sometimes removes the more-complete Persona (eg, [1], above), which leads to clients showing AB and C as distinct (when there should only be ABC). 2. The key-file backend needs to end up with only 1 entry when a Persona gets linked with another. I believe there's some internal hash that just gets serialized as relationships.ini when this happens. The best way to fix this would be to prevent partial duplicates in this hash in the first place.
We should be sure that cases like this also get fixed (include it in a new test): [0] protocol=A;B; [1] protocol=C;D; [2] protocol=A;B;C;D; (Upon the next save, [0] and [1] should be eliminated). As well as trickier cases like: [0] protocol_1=A; protocol_2=B; [1] protocol_2=C;D; [2] protocol_1=A; protocol_2=B;C;D;
Furthermore, if the key-file backend detects any partial duplicates during prepare(), it should save the file to disk just before it returns from the async prepare() call. This will normalize the key-file for users who have upgraded Folks since this bug is fixed yet haven't added new links. Otherwise they could continue to see the consequences of this bug (eg, bug #642252).
Philip, could you come up with a fix for this?
Surely this isn't about removing duplicates - itt should be about the core of libfolks characterising some links as "add a field to this entry" rather than "create a new entry". Surely this duplicate removing inside the relationships key-file backend isn't going to help much when [0] and [1] are entries in e-d-s with other fields, and [2] should never have been created.
The key-file backend was designed to do this (i.e. this behaviour isn't a bug). The individual aggregator sorts out the soup of personas given to it by the key-file backend, and any “fix” for this bug would effectively be partially reimplementing the individual aggregator in the key-file backend. What sounds like a bug is that the more-complete persona is being removed in some cases. Can you give a concrete test case, since I don't recall ever seeing this before?
(In reply to comment #5) > What sounds like a bug is that the more-complete persona is being removed in > some cases. Can you give a concrete test case, since I don't recall ever seeing > this before? Right, so this is issue 1. in the original description. I couldn't reproduce it in the simple case described in the description. I /may/ have seen it myself but didn't recognize it at the time. I'll make sure all my contacts are linked up and see if I ever spot them separated.
Setting the milestone, since this is something we should fix (especially with the upcoming writable Tracker backend: bug #645413).
(In reply to comment #7) > Setting the milestone, since this is something we should fix (especially with > the upcoming writable Tracker backend: bug #645413). That is, this is a general problem we should solve for both backends and/or in libfolks.
Is this still a problem?
Note that this is similar to the problem in bug #653728 and may be fixed at the same time.
Punting bugs that won't be fixed by Folks 0.6.0.
(In reply to comment #10) > Note that this is similar to the problem in bug #653728 and may be fixed at the > same time. It's dissimilar in that it matters to nobody if the key-file backend has spurious personas, since they can't be accessed any way other than through folks. ∴ Closing.