Pidgin doesn't synchronize blist.xml completely after moving buddy on AIM protocol

[varchar255]

There are a lot of tickets on moving buddies, but I searched and couldn't find one with this problem. In particular it is not a dupe of http://developer.pidgin.im/ticket/2921, although they sound similar.

When moving buddies on the AIM protocol, Pidgin correctly updates its local blist.xml and the buddy is moved properly server-side. However, if you log in on a different machine with an old blist.xml, Pidgin checks the server list and adds the new buddy, but fails to remove the old one from the local list. The end result is the old buddy remains on the list in the original group and is viewable in the buddy list, but doesn't exist on the server. This can cause odd problems such as if you move the buddy from the new group back to that original group, it gets deleted (presumably because Pidgin thinks the buddy already exists in the original group, so it sends a delete signal but not an add signal?)

Steps to reproduce (using a single computer):
1) Start with buddy in GroupA on AIM protocol.
2) Make a copy of blist.xml
3) Move buddy to GroupB.
4) Exit Pidgin.
5) Delete blist.xml and replace it with the copy made in step 2.
6) Run Pidgin.

Observed behavior: Buddy now exists in GroupA and GroupB.
Expected behavior: Buddy should be in GroupB only.
Fix: When checking the server list, Pidgin should recognize that the buddy does not exist in GroupA and remove it from the local list (being sure NOT to remove the GroupB buddy as well).

The reason for making a copy of blist.xml is to simulate the behavior when using two machines, where one blist.xml would be updated and another would not. While real users are not likely to follow those steps, I imagine running Pidgin on multiple computers or dual-booting is more common and this bug will appear in those cases.

I first saw this on Pidgin 2.2.2, running on Windows XP and Ubuntu Gutsy. Haven't checked if this happens with other protocols.

[deryni]

This is something pidgin has historically avoided doing quite on purpose. This is because historically many of the IM services were particularly prone to losing one's entire buddy list (sometimes temporarily but sometime permanently), at which point at login time they would just send an empty buddy list to the client. If pidgin assumed that meant the user had deleted all the buddies in the list the local copy would have served no purpose. While it is no longer the case that such losses are frequent they still do occasionally occur and would still trigger such undesirable behaviour.

What pidgin needs (and has needed for *ages*) is a functional and friendly list-sync manager dialog which pops up when the server list and the local list disagree and which allows the user to specify what local changes are authoritative and what remote changes are.

[MarkDoliner]

Er, no, we should really just trust the server list. Especially for oscar. I've never actually seen a report of someone losing their buddy list on ANY protocol. It's all hearsay as far as I'm concerned.

I think it's pretty foolish for us to assume that an IM network is so incompetent that it loses the user's most valuable piece of information.

[deryni]

I will grant that it is 'reasonably' safe to assume that if a buddy that had previously been in GroupA is now in GroupB that the move was intentional and that we can drop the local copy of GroupA, I am not at all willing to grant that assuming the utter deletion was correct is the appropriate thing to do. That being said I see no reason why we should assume either, since as you commented, the buddy list is the "user's most valuable piece of information" and as such we should really just get the out-of-sync dialog and use that for all conflict resolution, with the ability to set things like "always trust the server" or "always trust the local list" we can even default the dialog to having selected "trust the server".

[bernmeister]

varchar255: Is this still an issue on 2.5.8?

MarkDoliner/deryni: What's the story here...should a new ticket/task be created for a buddy list sync dialog?

[MarkDoliner]

I'm pretty strongly against a buddy list sync dialog. It's not something the user should have to deal with. No other client has one, and there's no logical reason to justify us having one. The list stored on the server should always take precedence.

"Pidgin fails to remove the old buddy from the local list" If this is really happening it's a bug. There is currently code in the oscar protocol plugin to remove local buddies that no longer exist in the server-side list. If this bug exists then this code might be buggy. The function responsible is purple_ssi_parselist().

[varchar255]

Replying to bernmeister:

varchar255: Is this still an issue on 2.5.8?

Yes, this issue still exists on 2.5.8.