Fix bugs relating to joining zannels for a quick release.
authorMichael Poole <mdpoole@troilus.org>
Sun, 13 Nov 2005 15:28:17 +0000 (15:28 +0000)
committerMichael Poole <mdpoole@troilus.org>
Sun, 13 Nov 2005 15:28:17 +0000 (15:28 +0000)
git-svn-id: file:///home/klmitch/undernet-ircu/undernet-ircu-svn/ircu2/branches/u2_10_12_branch@1546 c9e4aea6-c8fd-4c43-8297-357d70d61c8c

ChangeLog
include/patchlevel.h
ircd/m_create.c
ircd/m_join.c

index 11955ce9d0e198fd0e6443b92b9dd9ef5d12d15e..daad290d8bf2e877b21d63ef520fd0503029d41a 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2005-11-13  Michael Poole <mdpoole@troilus.org>
+
+       * include/patchlevel.h (PATCHLEVEL): Update for release.
+
+2005-11-13  Carlo Wood <run@alinoe.com>
+
+       * ircd/m_create (ms_create): Accept CREATE for zannels.
+
+       * ircd/m_join.c (m_join): MODE +o for a zannel must come from the
+       server for compatibility with older versions.
+
 2005-11-12  Michael Poole <mdpoole@troilus.org>
 
        * include/patchlevel.h (PATCHLEVEL): Bump for pre03.
index 678dda23a1cc3a58a36facf666b111e211f6eeed..3241de9aba215383590022458a23a99c5cf79af5 100644 (file)
@@ -18,7 +18,7 @@
  * $Id$
  *
  */
-#define PATCHLEVEL "pre03"
+#define PATCHLEVEL "03"
 
 #define RELEASE ".12."
 
index 8219f09e0c4a556826dbca7ee9594f89db3f8876..6cb3db2c80d6673a863173355e232a4a7795172a 100644 (file)
@@ -168,7 +168,27 @@ int ms_create(struct Client* cptr, struct Client* sptr, int parc, char* parv[])
       /* Check if we need to bounce a mode */
       if (TStime() - chanTS > TS_LAG_TIME ||
          (chptr->creationtime && chanTS > chptr->creationtime &&
-          chptr->creationtime != MAGIC_REMOTE_JOIN_TS)) {
+          chptr->creationtime != MAGIC_REMOTE_JOIN_TS &&
+          /* Accept CREATE for zannels. This is only really necessary on a network
+             with servers prior to 2.10.12.02: we just accept their TS and ignore
+             the fact that it was a zannel. The influence of this on a network
+             that is completely 2.10.12.03 or higher is neglectable: Normally
+             a server only sends a CREATE after first sending a DESTRUCT. Thus,
+             by receiving a CREATE for a zannel one of two things happened:
+             1. The DESTRUCT was sent during a net.break; this could mean that
+                our zannel is at the verge of expiring too, it should have been
+                destructed. It is correct to copy the newer TS now, all modes
+                already have been reset, so it will be as if it was destructed
+                and immediately recreated. In order to avoid desyncs of modes,
+                we don't accept a CREATE for channels that have +A set.
+             2. The DESTRUCT passed, then someone created the channel on our
+                side and left it again. In this situation we have a near
+                simultaneous creation on two servers; the person on our side
+                already left within the time span of a message propagation.
+                The channel will therefore be less than 48 hours old and no
+                'protection' is necessary.
+           */
+          !(chptr->users == 0 && !chptr->mode.apass[0]))) {
        modebuf_init(&mbuf, sptr, cptr, chptr,
                     (MODEBUF_DEST_SERVER |  /* Send mode to server */
                      MODEBUF_DEST_HACK2  |  /* Send a HACK(2) message */
index 9056c077837cb09dde7a6d3d4e964c3976b35320..b5a675cb20cb7d3093caf3b9c36ed8a65fb7372f 100644 (file)
@@ -245,10 +245,18 @@ int m_join(struct Client *cptr, struct Client *sptr, int parc, char *parv[])
 
       joinbuf_join(&join, chptr, flags);
       if (flags & CHFL_CHANOP) {
+        struct ModeBuf mbuf;
+#if 0
         /* Send a MODE to the other servers. If the user used the A/U pass,
         * let his server op him, otherwise let him op himself. */
-        struct ModeBuf mbuf;
        modebuf_init(&mbuf, chptr->mode.apass[0] ? &me : sptr, cptr, chptr, MODEBUF_DEST_SERVER);
+#else
+       /* Always let the server op him: this is needed on a net with older servers
+          because they 'destruct' channels immediately when they become empty without
+          sending out a DESTRUCT message. As a result, they would always bounce a mode
+          (as HACK(2)) when the user ops himself. */
+       modebuf_init(&mbuf, &me, cptr, chptr, MODEBUF_DEST_SERVER);
+#endif
        modebuf_mode_client(&mbuf, MODE_ADD | MODE_CHANOP, sptr,
                             chptr->mode.apass[0] ? ((flags & CHFL_CHANNEL_MANAGER) ? 0 : 1) : MAXOPLEVEL);
        modebuf_flush(&mbuf);