mIRC Home    About    Download    Register    News    Help

Print Thread
/write -d not preserving user permissions #200993 16/06/08 12:30 PM
Joined: Mar 2006
Posts: 6
Z
zzattack Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
Z
Joined: Mar 2006
Posts: 6
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.

Re: /write -d not preserving user permissions [Re: zzattack] #201011 16/06/08 09:46 PM
Joined: Dec 2002
Posts: 5,036
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,036
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.

Re: /write -d not preserving user permissions [Re: Khaled] #201021 17/06/08 06:44 AM
Joined: Jan 2004
Posts: 1,660
maroon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,660
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.

Re: /write -d not preserving user permissions [Re: zzattack] #201034 17/06/08 11:54 AM
Joined: Mar 2006
Posts: 6
Z
zzattack Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
Z
Joined: Mar 2006
Posts: 6
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 smile

Last edited by zzattack; 17/06/08 11:55 AM.
Re: /write -d not preserving user permissions [Re: Khaled] #201187 22/06/08 03:41 AM
Joined: Jan 2004
Posts: 1,660
maroon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,660
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.