[ICQ/AIM] Possibly fix for broken privacy lists in some accounts (tickets #9034, #12549)
mark at kingant.net
Mon Nov 22 17:21:49 EST 2010
On Mon, Nov 22, 2010 at 9:31 AM, dustin <dzlists at arcor.de> wrote:
> On 22.11.2010 10:34, Mark Doliner wrote:
>> On Mon, Oct 18, 2010 at 2:51 PM, <dzlists at arcor.de> wrote:
>>> I couldn't find any remnants of the broken bid in the itemlist nor in the tlvlist loaded by
>>> parsedata() (family_feedbag.c).
>>> Anyway, just deleting the broken entry from the server worked. *snip*
>>> In this way, it was possible to repair the broken ICQ accounts *snip*
>> I don't think I followed this... Are you saying that certain items in
>> the buddy list are "broken"? What indicates that an item is broken?
> "Broken" in the sense that there seems to be an item stored on the
> server which does not appear in the client's ssi itemlist (or the
> corresponding tlvlist 0x00c8).
> This causes a "Cannot add buddy..." error when libpurple tries to use
> the same (gid, bid) combination when adding a blocking/visible/invisible
> entry. (likely the same bug as described in tickets #9034, #12549, #12933)
> I'm assuming there's actually a broken entry on the server because:
> 1. It's only a single (gid, bid) combination that doesn't work, the bids
> before and after work fine.
> 2. After sending a delete (SNAC_SUBTYPE_FEEDBAG_DEL) for this (gid, bid)
> the error will disappear. (However i've no idea if there's any relevant
> data that gets deleted by this.)
Ahhh, I see now. So you're saying that this broken entry doesn't
appear in OscarData->ssi.official or OscarData->ssi.local? I wonder
if that's a server bug (they fail to send us an entry for that
gid+bid), or a client bug (we receive the entry for that gid+bid, but
we discard it for some reason).
>>> Can such a deletion also be done from a plug-in (e.g. by injecting data into the ssi.official or
>>> ssi.pending list of an account)?
>>> If so, I would like to write one (if this approach makes any sense at all).
>> Plugins don't really have access to internal oscar data structures.
>> But if this is something that should be done for all AIM and ICQ buddy
>> lists then it seems like the most appropriate place to do it is in
>> aim_ssi_cleanlist() in libpurple/protocols/oscar/family_feedbag.c
> I think the only way to find those entries is actually receiving an
> 0x0003 error (item already exists) when trying to add an item.
> This seems to be a rare bug, and having an automatic correction for this
> may have harmful side effects (possibly deleting legitimate entries in a
> different situation...).
> So I thought keeping a manual fix for this, and preferably far away
> from libpurple's normal functioning, would be better.
Hrm. Good point. I guess we should determine if this is a client bug
(make sure we're not discarding the entry for some reason). If it's
not a client bug, then I'd argue that we SHOULD include code to
automatically correct the problem. I think it happens frequently
enough, and the downside of possibly deleting a single item is minor
enough to justify it.
Although I wonder, do official ICQ clients have this same problem?
How do they work around it?
More information about the Devel