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.
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.
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?
