[ICQ/AIM] Possibly fix for broken privacy lists in some accounts (tickets #9034, #12549)
dzlists at arcor.de
Tue Nov 23 13:45:59 EST 2010
> Mark Doliner wrote:
>> 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).
>>> 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
> error handling?
> 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?)
Or maybe the entries are some server data after all, only lacking the ssi
itemlist reference .
I've just written some hack to automatically delete those entries, and I
found several of those on my regular and a test account.
For a start it may be sufficient to consider lower bids as reserved and
have aim_ssi_itemlist_add() generate only bids from 0x0100 upward or something.
If that doesn't work and the errors keep coming back one could still
include an automatic delete for weird entries.
More information about the Devel