View Issue Details

IDProjectCategoryView StatusLast Update
0002040unrealircdpublic2013-05-07 06:24
Reporteraquanight Assigned Tonenolod 
Status resolvedResolutionfixed 
PlatformX86OSWindowsOS VersionXP Professional
Product Version3.2.1 
Target Version3.3-alpha0Fixed in Version3.4-alpha1 
Summary0002040: +L without +l?
Description+L requires +l before being set. But unsetting +l does not remove +L - regardless of who does it (uline, ircop, chan owner, chanop, whatever).
Steps To Reproduce- Usermode -o and the works.
- Create and register a channel. Don't mlock either of +l or +L. Hop to get +q/~.
- Set +lL 1 #Anything
- Set -l, and notice +L remains. Even MODE-read still shows +L being there.
Additional InformationIf +L is useless without +l, shouldn't both be unset at the same time?
TagsNo tags attached.
3rd party modules


has duplicate 0002757 closed channel modes +lL 
has duplicate 0002805 closed Simple mode error 
has duplicate 0003240 closed A small tweak to a channel mode 



2004-08-24 09:09

reporter   ~0007420

is there a need for -L om l?

maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it...

on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well...


2004-08-25 02:20

reporter   ~0007422

Hm... yes I thought of this.

>maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it..

I'm thinking that typically +l and +L would be set in mlock - at least when used together. I can imagine using +l for join controls (though +f does a better job of this :P ), but in such a case would you use +L? I don't quite see the point in sending massjoinflooders to a different channel - flooding it instead :) .
Also, there's a way to "disable the limit" but still leave the channel +l: (try to) set the limit to 2147483647 which is probably the effective limit when -l :P .

>on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well..

I had considered that if this were done, +l wouldn't be able to be unset (maybe changed to a different number, but not to "set" to 0 (aka unset)) for the reason you mentioned that nonowners would otherwise become able to -L...

I guess what we'd need is to look and see how +L is being used (if it's being used :/ )... maybe... problem is I don't know anyone that uses +L :P maybe the coders do... *poke*


2004-08-26 05:46

reporter   ~0007427

I use +L personally, a useful tool for locking say, filesharing channels. Redirect them to the main channel (>:)). The one thing I don't like about +L is it is owner-only, meaning if you don't have services, you have to +q yourself to use it. Makes sense, I suppose... but yeah. :) "if you cant trust your chanops, dont make them chanops" >:)


2004-08-26 20:29

reporter   ~0007432

Well I notice that with +i and +K, -i also does -K:

-> MODE #Test +iK
<- :aquanight! MODE #Test +iK
-> MODE #Test -i
<- :aquanight! MODE #Test -iK

So in a way, it's inconsistant. /me wonders what other modes should be tried...
In this case, I can understand: +K is meaningless because /KNOCK can't be used on a channel that isn't +i (though +R isn't enough either?). But on the same token, +L has no meaning on a "limitless" channel.


2004-08-26 22:46

reporter   ~0007433

Maybe +L should always redirect the users if +l isn't set


2004-08-27 02:31

reporter   ~0007438

>Maybe +L should always redirect the users if +l isn't set

That can be acheived with +l - set it to 1 :P .


2004-08-27 19:51

reporter   ~0007439

Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p


2004-08-28 05:46

reporter   ~0007444

> Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p

I don't see where you get that logic from. You were suggesting +L do something without +l. The point is: it doesn't, so why does it "stick around" without it's partner?


2004-08-28 08:52

reporter   ~0007446

You say +L should be unset at the same time as +l, but there is this +L=owner-only problem.
So why don't make +L an independent mode and forget -L on -l.


2004-08-28 19:07

reporter   ~0007447


I already metioned how this could be handled: if +L is set, a normal chanop could be prevented from doing -l at all, but using +l to change the limit would be okay.


2004-08-31 02:23

reporter   ~0007465

+L is a handy feature for large channels. Suppose your channel usually gets 80 people. You wouldn't want them all talking at once in #channel-1, so you'd set +lL 40 #channel-2. This feature should stay in the IRCd.

I don't see the reason to set -L on -l. What if someone wants to temporarily stop the channel link? For example, unset +l and then set it again later? I don't see why this mode should be changed.

+L is also set for channel owner for a reason; You wouldn't want any op to just link your channel to his. This should not be changed.


2004-08-31 02:27

reporter   ~0007466

>I don't see the reason to set -L on -l. What if someone wants to temporarily
>stop the channel link? For example, unset +l and then set it again later? I
>don't see why this mode should be changed.

As I mentioned, in most cases you'd probably have +l mlocked or something.

If you have a floating limit however, then it is possible to "disable" it by simply changing the limit to a ridiculously high value. Besides, if you can't trust the chanops, why are they chanops?


2004-09-03 04:38

reporter   ~0007480

"Besides, if you can't trust the chanops, why are they chanops?"

Ok, if you've ever understood the purpose of a hierarchy, you'll know my whole point. Take an army, for example. People don't just go from Private to Warrant Officer right away. They do however, get to the next step: the rank of Corporal. The Warrant Officer can lead the platoon, whereas the Corporal can only lead a squad of four inside the platoon. Now, you're saying this: Why shouldn't the Corporal be able to lead the whole platoon? (if you can't trust the chanops, why are they chanops? --> if you can't trust the Corporals, why are they Corporals?). It all comes down to the hierarchy system. You don't just give someone full privileges right away.


2004-09-03 15:39

reporter   ~0007481

Hm... it's not quite the same thing...

Giving someone chanop on a channel is usually a sign of trust. Would you give ops to just any random person that asked for it? Probably not.

*pokes coders*


2004-09-04 16:38

reporter   ~0007520

Last edited: 2004-09-04 16:40

maybe the purpose is coz of "thinking ahead" -

add a limit, add a +L link, remove the limit, in a flood, simple add the limit and you *dont* need to the add the link coz it there...

same story with +K, add +i add +K, remove the +i, and ur reassured the next time u set +i u *WONT* get a Knock flood becuz +K was never removed in the first place....

*edit* prevention is better than cure...

edited on: 2004-09-04 16:40


2004-09-04 16:41

reporter   ~0007521

Um. No. +K *IS* removed when you set -i.


2007-04-17 17:41

reporter   ~0013485

Last edited: 2007-04-17 17:44

This should behave identical to +i/+K regardless of how we actually want both mode sets to behave. Let's recap:

You CANNOT set +K without +i.
You CANNOT set +L without +l.

+K without +i is worthless, it does nothing, knocking isn't allowed unless +i is set.
+L without +l is worthless, it does nothing, joining won't kick you to a different channel unless +l is set and the limit is reached.

Now, allowing the modes to remain set so that a user can simply +i or +l a channel and let the defaults take over certainly would be nice, as it makes it easier for the user.

But disabling the modes automatically also makes it easier for the user who uses them in the ways intended.

Here's what I think should happen:

If a set of modes such as i/K, l/L can coexist or exist on its own without causing any behavior issues in Unreal, then I think we should leave it up to the user to decide what they want to do. In this case, the user could set +L and +K without +l or +i being set.

The only problem I can see with this is that users who don't fully understand what the modes are for won't then have the incite given to them by the errors that are currently provided.

So it seems to come down to:

Would allowing users to set the modes and remove them manually be an issue?
Is it worth the possibility of confusing users?

And if not, then we simply make +l/+L behave exactly as +i/+K, and -L when -l is set.

Shining Phoenix

2007-04-18 04:51

reporter   ~0013496

WolfSage: Microsoft Word does stuff that the programmers thought would be helpful. I hate it. Changing user's channel modes for them is similar. I think we should let them set unset iKlL whenever they want, and not have the server do it for them.


2007-04-18 04:59

reporter   ~0013501

+l should remove +L due to the fact on net.join +L won't be set cos +l isn't set, and we have a desync.


2007-04-18 19:48

reporter   ~0013560

Your logic here baffles me Sts =)


2007-04-18 22:40

reporter   ~0013570

what sts is saying, i believe, is that the modes arnt reset after a netsplit or during desync, so the server trying to force +L which cannot be set without +l would break something. This has been an issue for quite some time, and should have been fixed, but i guess its going to be now


2007-04-27 13:13

reporter   ~0013892

Another issue. +L can only be set/unset by +q users.. if we allow -l to take away +L, we would subvert this .. just noticed this while trying to add this functionality.


2007-04-27 13:28

reporter   ~0013893

when +L is active only allow +q to remove -l


2007-04-28 08:26

reporter   ~0013910

WolfSage suggest making the modes independent (ie, +L doesnt require +l to be set), which is feasible. Any comments? This will break backwards compatibility, but it is needed :P


2007-05-04 08:36

reporter   ~0013998

Patched in .2387, removing dependancy on +l for +L. This will be backwards compatible as well, SJOIN doesn't care (TM) and mode doesn't either in case of a server sending it. So this will be just a client protocol modification. Also pulled out a modification that got in accidentially. The reason it is feasible is due to the fact +l 0 and +l 1 will be, honestly, the same, and we can read +l 0 as being +l 1 if the channel has one user that keeps it open.


2011-07-19 14:08

administrator   ~0016704

Although I personally wouldn't care much, it seems there's a tendency to decouple these modes. So we'd need to re-port this patch from old 3.3 to new 3.3.


2013-05-07 06:24

reporter   ~0017517

I decoupled this a while ago.

Issue History

Date Modified Username Field Change
2004-08-24 02:05 aquanight New Issue
2004-08-24 09:09 medice Note Added: 0007420
2004-08-25 02:20 aquanight Note Added: 0007422
2004-08-26 05:46 w00t Note Added: 0007427
2004-08-26 20:29 aquanight Note Added: 0007432
2004-08-26 22:46 yodaone Note Added: 0007433
2004-08-27 02:31 aquanight Note Added: 0007438
2004-08-27 19:51 yodaone Note Added: 0007439
2004-08-28 05:46 aquanight Note Added: 0007444
2004-08-28 08:52 yodaone Note Added: 0007446
2004-08-28 19:07 aquanight Note Added: 0007447
2004-08-31 02:23 al5001 Note Added: 0007465
2004-08-31 02:27 aquanight Note Added: 0007466
2004-09-03 04:38 al5001 Note Added: 0007480
2004-09-03 15:39 aquanight Note Added: 0007481
2004-09-04 16:38 White_Magic Note Added: 0007520
2004-09-04 16:40 White_Magic Note Edited: 0007520
2004-09-04 16:41 aquanight Note Added: 0007521
2006-01-22 13:59 syzop Relationship added has duplicate 0002757
2007-04-16 10:40 stskeeps Relationship added has duplicate 0002805
2007-04-17 17:41 WolfSage Note Added: 0013485
2007-04-17 17:42 WolfSage Note Edited: 0013485
2007-04-17 17:44 WolfSage Note Edited: 0013485
2007-04-18 04:51 Shining Phoenix Note Added: 0013496
2007-04-18 04:54 stskeeps Relationship added has duplicate 0003240
2007-04-18 04:59 stskeeps Note Added: 0013501
2007-04-18 04:59 stskeeps Status new => acknowledged
2007-04-18 19:48 WolfSage Note Added: 0013560
2007-04-18 22:40 Bricker Note Added: 0013570
2007-04-27 13:13 stskeeps Note Added: 0013892
2007-04-27 13:28 vonitsanet Note Added: 0013893
2007-04-28 08:26 stskeeps Note Added: 0013910
2007-05-04 08:36 stskeeps Status acknowledged => resolved
2007-05-04 08:36 stskeeps Fixed in Version => 3.3-alpha0
2007-05-04 08:36 stskeeps Resolution open => fixed
2007-05-04 08:36 stskeeps Assigned To => stskeeps
2007-05-04 08:36 stskeeps Note Added: 0013998
2011-07-19 14:05 syzop Assigned To stskeeps =>
2011-07-19 14:05 syzop Status resolved => needs re porting
2011-07-19 14:08 syzop Note Added: 0016704
2011-07-19 17:11 syzop Target Version => 3.3-alpha0
2013-05-07 06:24 nenolod Note Added: 0017517
2013-05-07 06:24 nenolod Status needs re porting => resolved
2013-05-07 06:24 nenolod Fixed in Version 3.3-alpha0 => 3.4-alpha1
2013-05-07 06:24 nenolod Assigned To => nenolod