Most of you reading this will no doubt already have some idea of how file permissions are handled when moving or copying files to and from NTFS drives. The following behaviour is expected:
- When copying a file from one NTFS volume to a folder on another volume the file inherits the permissions of the destination folder.
- When copying a file from one folder to new a folder on the same NTFS volume the file inherits the permissions of the destination folder.
- When moving a file from one NTFS volume to a folder on another volume the file inherits the permissions of the destination folder.
- When moving a file from one folder to new a folder on the same NTFS volume the file retains the permissions.
Microsoft explicitly state this in their KB article http://support.microsoft.com/kb/310316.
By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.
In addition to this Microsoft also state the same thing in all of their training material for certification. I have also searched the Internet looking at various blogs, forums and they all say the same thing. Up until last week I also believed this as I was taught this when studying for Microsoft Certification. It is actually not true, well not entirely anyway. In my bullet points above the first 3 statements are correct; the 4th one however, depends on certain circumstances. Under certain conditions the file moved will actually inherit permissions of the destination folder. Surprisingly this has been the case since XP as well (I haven’t got access to earlier OS’s but it may also be the case with them). Before explaining what really happens and why let’s have a look at why this is thought to be true.
How It Is Meant To Work
The idea behind this behaviour stems from the first 3 procedures above actually creating a new file whereas the 4th one doesn’t. The first two procedures are obvious, they both create new files (a copy) but the third one it isn’t so clear. When you move a file to a different NTFS volume what actually happens is that it is copied to the new volume first (therefore creating a new file) then deleted from the original volume. When creating a new file it has to assign ACLs to it so where does it get them from? It inherits them from the destination folder as there is no other way.
When you move a file within the same volume all that happens is that the logical path (c:my docsmy_file.txt) is changed. This is done in the MFT (Master File Table). For those of you that don’t know, the MFT is an index of all files stored on the hard drive of where to PHYSICALLY locate the data. For example an entry will be along the lines of:
The file c:my docsmy_file.txt is physically located at sector 5366 on the disk
When you move the file it just changes the entry like so:
The file c:my picturesmy_file.txt is physically located at sector 5366 on the disk
This is why when you move a 5 GB file to a new folder on the same drive it happens almost instantly, all that has happened really is that the entry in the MFT has changed; the physical data and it’s associated ACL’s hasn’t been touched. This is why when you move the file in the same volume it retains it’s permissions.
What Really Happens
This section is only about what happens when you move files from one folder to another on the same volume as it is the only discrepency from the MS article.
ACL’s are not stored with the file itself. Picture this scenario which is quite common:
- You have a folder with thousands of subfolders and files.
- On the parent folder you set the ACL to allow users modify rights only, no other permissions are set.
- The subfolders and files all have the tick box set to inherit permissions of their parent folder.
- NO permissions have explicitly been set on any of the subfolders and files.
As you no doubt know the end result is that users have modify rights to all files and folder due to them inheriting the permissions from the parent folder. Ask yourself this question, which would be the most efficient way to apply ACL’s in this scenario; apply one ACL in the MFT or individual ones for all the thousands files? I think we know the answer to that. I suspect that the NTFS file system applies one ACL on the parent folder but sets a flag on the subfolders and files to inherit permissions. This next bit is very important to understand; if this is the case then it means that the files themselves have NO ACLs. Why is this important you may ask? Well, when you move a file to another folder how does it retain these permissions/ACLs if it didn’t have any in the first place? It only had these permissions by having a flag set to inherit permissions of the parent folder, now that you have moved it to another folder it will no longer reference the old folder for permissions. I decided to test my theory and found it was correct. The file actually DOES inherit permissions of the parent folder, it DOES NOT retain the previous permissions.
I was naturally surprised to find this as I was led to belive otherwise for a long time. I wondered whether it was a recent change so i tried it in XP but found it behaved exactly the same way. There is one caveat…which is why in my opening statement I said this only occurs under certain conditions. IF permissions have been explicitly set on a file or subfolder it will create an ACL specifically for this file. When you move it to a new folder it’s logical path location is changed as already explained. Since the file has it’s own explicit ACL this time it DOES RETAIN it’s permissions.
So to summarise when moving files within the same volume it does retain it’s permissions if explicit permissions are used; this is because the file has it’s own ACL. If the file is set to inherit permissions and has NO explicit permissions set it DOES inherit permissions of the destination folder; this is because it has no ACL’s itself.
NOTE: At the bottom of the MS KB article it talks about making a registry change to make Windows Explorer handle permissions differently. Although similar to what I have described it is not the same. The registry change is applicible only when explicit permissions are used. In my article the behaviour occurs when explicit permissions are not used.
To be fair to the MS article if you read it in the context of that they are talking about explicit permissions it would be correct. Maybe this is actually what they mean but they haven’t said so, so it is techincally wrong. If they just added that one sentence in there at the beginning saying it applies to explicit permissions only it would be correct.