[ICQ/AIM] Possibly fix for broken privacy lists in some accounts (tickets #9034, #12549)
dzlists at arcor.de
Mon Nov 22 18:18:21 EST 2010
Mark Doliner wrote:
> 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).
I guess it's the server, because the entry does not appear even when
reading directly from the tlvlist. (using the patch I posted on 13.11.)
AFAICS there's no filtering before that.
(23:25:24) oscar: Reading items from tlvlist for account xxxxxxxxx:
gid=0x0000 bid=0x0000 list_type=0x0001 name=(null) [Group]
gid=0x0000 bid=0x0001 list_type=0x0004 name=(null) [PDInfo]
gid=0x0000 bid=0x0002 list_type=0x0005 name=(null) [PresencePrefs]
gid=0x0000 bid=0x0003 list_type=0x0020 name=ICQ-MDIR [ICQ-MDir]
gid=0x0000 bid=0x0004 list_type=0x0014 name=1 [Buddy Icon]
gid=0x0000 bid=0x0005 list_type=0x001d name=(null) [Vanity Info]
gid=0x0000 bid=0x0007 list_type=0x0019 name=yyyyyyyyy [Non-Buddy]
gid=0x0000 bid=0x0009 list_type=0x0029 name=facebook [Facebook]
(23:26:53) oscar: ssi: About to add a deny
(23:26:53) oscar: Adding item gid=0x0000 bid=0x0006 list_type=0x000e
name=yyyyyyyyy [ICQDeny/Ignore] (data: 0 bytes).
(23:26:54) oscar: ssi: status is 0x0003 for a 0x0008 action with name no item
(23:26:54) oscar: ssi: Action 0x0008 was unsuccessful with error 0x0003
>> 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.
Maybe this could be done in purple_ssi_parseack() [oscar.c] as part of
in aim_ssi_sync(): save the last addition to the item list in some place if
gid == 0.
in purple_ssi_parseack(): if error is 0x0003 and item does not exist in the
itemlist => delete (or give a special dialog window?)
> Although I wonder, do official ICQ clients have this same problem?
> How do they work around it?
Ignoring the problem. ;-)
It seems like only libpurple uses bids in ascending order, others have some
kind of randomization...
(01:40:27) dump: gid=0x0000 bid=0x2180 list_type=0x0003 name='xxxxxxxxx'
(01:40:27) dump: gid=0x0000 bid=0x21e2 list_type=0x0003 name='yyyyyyyyy'
(01:40:27) dump: gid=0x0000 bid=0x7d8c list_type=0x0003 name='zzzzzzzzz'
(These are invisible entries from Miranda, but ICQ7 and qip look similar.)
More information about the Devel