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.