pegasus/unrealircd
1
0
Fork 0
mirror of https://github.com/unrealircd/unrealircd.git synced 2026-07-09 22:13:11 +02:00
Code Activity

Send nick collision kill with a winner to the losing side only. Trust the NICK is in-flight to that server and that it will kill his own and assign ours the winner. This fixes a bug until now where it was killing the wrong user (reproduced locally) and prevents re-introducing of our client which we will never do correctly. (#1977). If you can present a legit case where this is wrong, let me know.

Browse Source
This commit is contained in:
Bram Matthys
2015-07-19 19:47:41 +02:00
parent 8b039335d6
commit 87c0bbed3c
1 changed files with 20 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/modules/m_nick.c
+20 -20
View File
@@ -812,30 +812,30 @@ DLLFUNC CMD_FUNC(m_nick)
if ((differ && (acptr->lastnick < lastnick)) ||
(!differ && (acptr->lastnick > lastnick)))
{
/* acptr (our user) won, let's kill sptr (their user),
** and reintroduce our "correct" user
*/
/* acptr (our user) won, let's kill sptr (their user) */
ircstp->is_kill++;
/* Kill the user trying to change their nick. */
sendto_server(cptr, 0, 0,
":%s KILL %s :%s (Nick collision: %s <- %s)",
me.name, sptr->name, me.name,
sptr->from->name, acptr->from->name);
sptr->flags |= FLAGS_KILLED;
(void)exit_client(NULL, sptr, &me, "Nick collision");
/*
* Introduce our "correct" user to the other server
*/
/* Kill their user. */
sendto_one(cptr, ":%s KILL %s :%s (Nick Collision)",
me.name, parv[1], me.name);
send_umode(NULL, acptr, 0, SEND_UMODES, buf);
sendto_one_nickcmd(cptr, acptr, buf);
if (acptr->user->away)
sendto_one(cptr, ":%s AWAY :%s", acptr->name,
acptr->user->away);
send_user_joins(cptr, acptr);
sptr->flags |= FLAGS_KILLED;
(void)exit_client(NULL, sptr, &me, "Nick collision");
/* Previously we did the following two things too:
* 1) Send the KILL to ALL servers.
* This is confusing, they might kill our nick instead.
* 2) Re-introduce our user.
* That would fix #1 but it can still cause strange issues
* and we always forget to 'sync' information below so
* this was never in full.
* I changed it so we just:
* 0) Kill their nick
*
* Most likely our own 'nick' is in-flight to cptr.
* They'll introduce our nick as it will 'win'.
*
* I suppose there could be some other deynch which is now
* unhandled, but how? Prove it to me and I'll look into
* it. -- Syzop
*/
return 0; /* their user lost, ignore the NICK */
}