I found that mIRC wasn't suitable for editing my hosts file. I was trying to relay some data through mIRC, but it seemed my hosts file just did not work. Some researching revealed that the user "NETWORK" needs to have read permissions on the hosts file. After a little testing, I can conclude that mIRC's /write -d switch does not preserve the user permissions for files.

You can reproduce this behaviour by creating file, say c:\test.txt. The file doesn't need actual content. Now, right click this file in windows explorer and hit Properties, go to the Security tab, click the Add button in the middle and add a few users to the list (in my case, user "NETWORK"). Now, in mIRC, try a simple //write -d c:\test.txt. Next, check the permissions for this file, you'll see they're gone.

The reason for this is that /write -d requires the creation of a new file which is assigned permissions by Windows based on the permissions of the folder where it was created and/or the mIRC process permissions.

Most file-related features in mIRC use this same method: if mIRC is updating a file, it first creates a copy of it, updates the copy, and if successful, it deletes the old file and renames the copy. This ensures that if there is an error while writing to the new file, you will not lose the original file.

File permissions are complex - while mIRC could try to copy the original file/user permissions and apply them to the new file, it's likely that there are situations where this would not work unless the mIRC process itself has sufficient permissions. I'll look into this a little more to see if I can find a solution for the next version.

One solution could be to add a new switch to /write that would change it from wrapping things up by deleting the original and renaming the updated copy as the original - to instead write the contents from the updated copy on top of the original, then delete the copy.

This way the original never gets deleted and loses its permissions. With the optional switch, only those needing the permissions preserved would be subjected to the extra burden of copying from the update-copy instead of renaming it.

I had figured the explanation would be something of such tendency. I really doubt Windows will allow for such operations when mIRC does not have enough rights.

Edit: after reading again, my 'solution' was just posted above

I wanted to also mention that the issue of permissions also comes into play when using /rename not just /write.

With the change to having mIRC default to have the download folder beneath Application Data, renaming (moving) a downloaded file to another folder on the same drive letter causes the file to keep the permissions of the source folder, regardless of the destination folder's permissions. When renaming to a different drive letter, the destination file is given permissions from the destination folder.

I don't think /rename should be changed to be doing a copy+delete, as that can add extra work for the system. Either a new switch to make /rename do a copy+delete, or a mention of this issue in the help file section for /rename should probably be sufficient.