Drocket wrote: This is a problem that happens sometimes with other files in XP Home, but for some reason, it seems to happen rather often with UO (it happens to me all the time, because I'm constantly fiddling with UO files, so much so that I made a batch file to fix it.)
For those of you that are interested in the "Where's and why fors" and those of you who would like to adjust your practices so that this occurs less frequently.
First, this is an unintended side effect of a NTFS feature. Because the NTFS permissions are masked from the user in Windows XP Home it can be extremely annoying.
Here is a step by step of the process most users go through when downloading the wodli.cfg file followed by an explaination of where the permissions were confused and why.
1. User Snuffy Downloads wodli.cfg file to his Desktop
2. User Snuffy opens Windows explorer and drags and drops the wodli.cfg into the Ultima Online folder.
Obviously these steps will vary somewhat per user but generally the common thread among people suffering this problem is "User downloads to desktop/or My Documents" then copies the file into the UO folder.
Now as most of you know when relocating a file you have two options, you can move the file or you can Copy the file. Windows handles these two operations differently with regards to file permissions.
Copy: Windows duplicates the file exactly, to include file security or ACL's (You did ask for a Copy) and places this newly created copy into the directory you specified with it's file permissions intact.
Move: File is moved to the new location however the File security (DACL) structure associated with the file is removed and it instead accepts the default permissions in the folder it has been moved too.
So the logical question is: "I can open/move/copy and delete the file on my desktop, so if the permissions are copied exactly how is it that I cannot delete it when I've moved it to the new folder?"
The answer: The desktop (in fact most Windows folders) use what is called inherited permissions, this means you set the permissions at the top level (C:\) and these permissions are allowed to be passed down to subsequent files. When you copy a file which has inherited permissions the Copy process records only the ACL's specific to that file which are "None".
Because the copy you created of the file has it's own DACL(Security Permissions) associated it does not inherit permissions from the folder it is placed in so it has a blank set of security permissions and this is why you cannot delete or access the file properly.
Best Practices: The best way to get around this "Feature" is to ensure that each time you relocate a file on your system you know exactly which procedure is taking place Copy or Move. The easiest way to accomplish this is, when you're planning to drag a file from one location to another, instead of holding down the left mouse button. Use the right mouse button, Drag and drop just like you normally would.. when you release the mouse button you will see a small popup menu appear with the following options "Copy Here", "Move Here", "Create Shortcut", and "Cancel".
It's a very useful habit to get into. How many times have you dropped a folder in the wrong place? This gives you the option to "Cancel" the action before it starts and armed with your new knowledge of NTFS Copy/Move you'll know when you're duplicating ACL's and when you aren't, so at least you'll be able to quickly identify and resolve future ACL Move/Copy problems.
GM Daeric