[IRCServices Coding] The case of the non-existant user

[Andrew Church]

     This shouldn't happen; if it does, it's either a Services bug or an
ircd bug.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>Odd scenario, and I am not sure whether services should/could support it, 
>but since it seems to be the cause of a particular chain of log messages, 
>it could well be something for the FAQ if it is not something that 
>should/could be supported.
>
>A user logs on to IRC, identifies to NickServ then joins a channel that he 
>has auto-op rights on. He then immediately changes nickname to another 
>nickname (registered or not). Services logs the fact that a mode change was 
>requested for a nonexistant user. The nicknames in the example are not 
>linked. 
>
>>From logs:
>
>[channel]
>[14:38] Damon (damon at xxxx) joined #channel.
>[14:38] Nick change: Damon -> Memphis
>
>[Services.log]
>[Mar 02 14:38:59 2002] nickserv/main: Damon!damon at xxxx identified for nick 
>Damon
>[Mar 02 14:38:59 2002] channel: MODE #channel +o for nonexistent user Damon
>[Mar 02 14:39:13 2002] nickserv/main: Memphis!damon at xxxx identified for 
>nick Memphis
>
>I have not managed to be quick enough to reproduce this 100% hence my lack 
>of knowledge on whether this affects linked nicknames, but in my defence it 
>is kinda late here and the timing is somewhat critical :). I suspect that 
>it may apply to linked nicknames as well but assuming that services logs an 
>error returned by the attempt to set a mode, I imagine the linked nick 
>would trigger another test which may make mitigate the problem from a 
>user's perspective.
>
>I guess it would quite complex for services to track the user and supress 
>the error as well as leading to potential circular lockup, so maybe just 
>one for the FAQ. 
>
>
>-- 
>Mark.
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding