mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2016
Posts: 5
T
tash Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Jan 2016
Posts: 5
With the "include network" option enabled on logging, when a server does not supply any network name, i.e. $network is null (think private and probably not-ideally configured servers), the following bugs happen:

  • No network name is appended to the logfile name, it results in #channelname.log
  • If "create folder" is enabled in logging options, no folder is created, logfiles for the "networkless" server end up in main directory

But for added bonus, things get wildly confusing when a channel by the same name is simultaneously used on a "network-named" server:
  • Without "use folders", the logfile from the "network-less" channel ends up in the wrong channel (I guess the one that is first re-entered), resulting in a wildly mixed backlog in that channel window.
  • When "use folders" is enabled, messages from both channels are mixed up into the respective logfile of the "network-named" server.

Suggestion: For logging with network name in filename/folder, fall back to server name if no network is stated.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. The behaviour you describe is intentional. If a network name is not provided, there is no network name to use in the log filename or for creating a folder.

With your suggestion, if a user had multiple servers defined for a network but had forgotten to assign a network name, the opposite issue would occur: the log files for the same network would be split across multiple files and folders and the user would have to figure out which log files belong where. If the user connects to multiple networks, that could mean tens of files or folders with fragments of logs.

This feature depends on the user specifying a network name for the server.

That said, it is actually possible for log files to intermix in other situations as well. To get around this issue, many long versions ago, mIRC included a change to prevent this (by creating unique log filenames with id numbers per server connection). Unfortunately, users disliked the feature as it made keeping track of log files in real-time, eg. using scripts, too complicated. So the feature was subsequently removed.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Quote:
With your suggestion, if a user had multiple servers defined for a network but had forgotten to assign a network name, the opposite issue would occur:
Except that wouldn't be an issue but a new feature, I think he is asking for that fallback.

I think a new option in alt+o>logging named like "fallback to server name" would be an idea.
Scripting wise, this can also now be solved by using /parseline to inject a network name, meaning you can currently 'script' the fallback to the servername, (maybe using only the hostname without the tld would be even better?).

Quote:
Unfortunately, users disliked the feature as it made keeping track of log files in real-time, eg. using scripts, too complicated
Really? mIRC can't magically guess a network name if one isn't provided, I don't see how they could possibly dislike it since it's the best thing that can be done in this situation (again, it's better than mixed log files). If they disliked that, I'm curious about what they said would be best then, cause after you removed that feature, they just ended up with the issue reported here confused


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: tash
when a server does not supply any network name, i.e. $network is null

Oh come on. These days there really is no excuse for this. Bug your server administrators instead. It's not mIRC's job to make up for their incompetence.

Originally Posted By: Wims
Really? mIRC can't magically guess a network name if one isn't provided, I don't see how they could possibly dislike it since it's the best thing that can be done in this situation [..]

I'm not sure, but if this was in reference to the mIRC 6.21 log change, then it applied to all log files, to solve what I think were problems arising from one mIRC instance connecting to the same network multiple times? In any case it was not limited to connections to servers lacking a network name, and as such it had a much larger impact.

I think the main problem back then was that if mIRC wasn't shut down properly, it would leave around a bunch of name.N.log files, which the user would have to merge back into the main log files by hand. It wasn't pretty.


Saturn, QuakeNet staff
Joined: Jan 2004
Posts: 1,358
L
Hoopy frood
Offline
Hoopy frood
L
Joined: Jan 2004
Posts: 1,358
If you add the server to the server list with a group name this is used for $network before connection, is it erased on connection to such servers?

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Quote:
In any case it was not limited to connections to servers lacking a network name
Right, I wanted to write in my post "assuming it was only doing it if there were no network name" but assumed it would be the case.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jan 2016
Posts: 5
T
tash Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Jan 2016
Posts: 5
Originally Posted By: Loki12583
If you add the server to the server list with a group name

Interestingly, that works, even though all my server connections are to the same address (same IP, different username/password, standard ZNC setup). Yes, this is a viable workaround, thank you.

As for the others: I guess the bug I would really name a "bug" is the intermixing of logfiles. I get that loading two logfiles into the backbuffer of one channel is probably caused by a different fallback (user switches logfile format). But two channels on two servers writing into the one and the same logfile cannot possibly be intended behaviour.

Joined: Jan 2016
Posts: 5
T
tash Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Jan 2016
Posts: 5
Originally Posted By: tash
Originally Posted By: Loki12583
If you add the server to the server list with a group name

Interestingly, that works

Spoke too soon. It would be viable if I connected directly to the servers. But since I connect to all of them through the same address, I need to keep that address (my ZNC server) out of the server list. Curiously, mIRC decides to override the password supplied with "/server -n" and apply the server list entry's password. Which is probably a new bug.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
As for the others: I guess the bug I would really name a "bug" is the intermixing of logfiles. I get that loading two logfiles into the backbuffer of one channel is probably caused by a different fallback (user switches logfile format). But two channels on two servers writing into the one and the same logfile cannot possibly be intended behaviour.

This is the intended behaviour. mIRC depends on the network name being set correctly to save log files to different filenames or folders. What you would need is an an option to be added to the logging options dialog to use the server address as the filename if the network name is not available.

However, I have also had requests from users who connect directly to the same host/ip address on different ports that are different networks and wanted mIRC to differentiate log filenames based on port numbers as well. So another option would need to be added for this case. Unfortunately, it would then apply to all servers that you connect to, even those that are on the same host/ip on different ports, which is probably not the desired behaviour.

Quote:
Curiously, mIRC decides to override the password supplied with "/server -n" and apply the server list entry's password. Which is probably a new bug.

This is also intentional. mIRC was designed to rotate the server selection based on network/group name (or network/group derived from a matching address in the servers list). So if you have a network with multiple servers, each of which has its own password setting, and you connect to a server on that network, mIRC will rotate through them.

The current method evolved over many years to make connecting to networks with multiple servers easier for non-technical users.

That said, I have only used ZNC servers myself for testing ZNC-related issues that users have occasionally reported, so for the specific use-case you are having difficulty with, I would need to install ZNC and see if I can come up with a solution, such as a "ZNC" option, that changes mIRC's behaviour in a ZNC context.

Joined: Jan 2016
Posts: 5
T
tash Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Jan 2016
Posts: 5
Khaled, thanks for coming back to this issue. I hope I'm not too annoying about it, I do appreciate all your work on what is still a daily use software for me. The bugs are not showstoppers by any means.

That said, please let's drop the issue about empty network names and the logfiles not being tagged with any network name. I can accept that this is just like it is, it's not a big deal either. However, taking this behaviour as a given:

Originally Posted By: Khaled
Quote:
But two channels on two servers writing into the one and the same logfile cannot possibly be intended behaviour.

This is the intended behaviour.

To be perfectly clear: I am talking about mIRC writing the logfile for both channels
#channelx on EFnet
and
#channelx on (no network name)
into
/<logdir>/Efnet/#channelx.log

I could comprehend a situation of both channels writing into /<logdir>/channelx.log, for historical or fallback reasons. But I just can't wrap my head around why the second channel -- definitely neither on a network nor a group named "EFnet" -- should intentionally write into /<logdir>/EFnet/#channelx.log

Quote:
Quote:
Curiously, mIRC decides to override the password supplied with "/server -n" and apply the server list entry's password. Which is probably a new bug.

This is also intentional.

Again, to be perfectly clear: I create a server connection, not connecting on creation, using
/server -n <servername:port> <password1>
Upon issuing /server to later actually connect this "pre-prepared" connection mIRC uses "password2" -- the password of the server in the server list. This doesn't happen with /server -m, only if not immediately connected using -n.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
Khaled, thanks for coming back to this issue. I hope I'm not too annoying about it, I do appreciate all your work on what is still a daily use software for me. The bugs are not showstoppers by any means.

No problem. It can sometimes take a lot of back and forth to track down the cause of an issue.

Quote:
To be perfectly clear: I am talking about mIRC writing the logfile for both channels
#channelx on EFnet
and
#channelx on (no network name)
into
/<logdir>/Efnet/#channelx.log

I could comprehend a situation of both channels writing into /<logdir>/channelx.log, for historical or fallback reasons. But I just can't wrap my head around why the second channel -- definitely neither on a network nor a group named "EFnet" -- should intentionally write into /<logdir>/EFnet/#channelx.log

Does the server address for the second channel match a server address, under any group, in the servers list? If it does, mIRC is trying to find a network name for that server by looking through your servers list. If it finds a matching server address in a group, it uses that groups name as the network name.

Is it possible that this is what is happening? If this is not the context, we may need find a way to reproduce this step by step with a new, clean install of mIRC and an empty servers.ini.

Quote:
Again, to be perfectly clear: I create a server connection, not connecting on creation, using
/server -n <servername:port> <password1>
Upon issuing /server to later actually connect this "pre-prepared" connection mIRC uses "password2" -- the password of the server in the server list. This doesn't happen with /server -m, only if not immediately connected using -n.

When you use /server with no parameters, it searches through your servers list for a matching server address so that it can 1) determine the network name, 2) find the next port to attempt to connect to (as mIRC cycles through ports to decrease load on any particular port for a server), and so on.

I can guess what has happened here: some time ago, a user very likely reported that using some combination of "/server" was not using the details defined for "address" in the servers list, so I extended /server to look up these details. However, we now have the opposite issue.

If we take into account /server features like finding a network/group name for an address and server/port cycling based on network/group/address name, that makes things a little more tricky when it comes to using the same address with different connection details for different networks.

I could add a /server switch, eg. -y, that would create a server window that would be permanently marked as not allowing any network/group matching/lookup or server/port cycling for the lifetime of that window. I haven't looked into it yet, so I am not sure how difficult this would be. Does that sound like it would resolve your issue?

Joined: Jan 2016
Posts: 5
T
tash Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Jan 2016
Posts: 5
Originally Posted By: Khaled
Does the server address for the second channel match a server address, under any group, in the servers list?

No. My server list is completely empty, due to the issue below.

Quote:

I could add a /server switch, eg. -y, that would create a server window that would be permanently marked as not allowing any network/group matching/lookup or server/port cycling for the lifetime of that window.

Uhm, okay, I just realize why I stumbled into that weird behaviour: It was to give a "networkless" server a group it identifies with, a workaround suggested above. So I would ... actually wanted to have it looked up I guess?

You know what, I'm good. Let's chalk all of this topic up to "general weirdness of a codebase grown over 20+ years" and let's forget about it.

Thanks for your time and responses though, it's well appreciated.

Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Could you allow a user specified log filename/path option?

E.g. a box where the user specifies what the filename/path should be and supports identifiers.

Log path: / $+ $iif($network,$v1,$server) $+ / $+ $chan $+ .log


Link Copied to Clipboard