I have explained this in a blog post http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ but it is also explained below.
When a file is copied, it has to create a brand new file and assign it a new set of permissions, so it gets the permissions from the parent folder as you know.
When a file is moved to another volume, what actually happens is that it is copied to the new volume and the old file is deleted. So the same process is repeated as above as it is a new file again and needs permissions set.
When the file is moved within the same volume, nothing really happens (at the disk level). It just changes the logical path location of the file. The actual data and physical file on the disk hasn't been touched or changed. Ever noticed when you move a 5GB file to another folder on the same drive, it is done almost instantly? This is why, because it actually hasn't moved but the pointer to where the file logically exists has changed. As it was not modified in any way, the permissions don't change also.
This is the reason for this behaviour.
Edit: Something I forgot to mention... The MS article isn't entirely accurate. MS quote:
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.
The above quote only applies to objects that have been given EXPLICITLY defined sec permissions (turn inheritance off).
As mentioned in my comments, it is all about keeping the ACL entries as efficient as possible. Consider the following example:
To keep the explanation simple, let's say you have a folder set to allow users modify rights only. Below this, there're thousands of files and none of them have explicit permissions set. It isn't very efficient to create ACLs for each file as they are exactly the same perms so it sets ONE ACL entry for the folder. This next bit is very IMPORTANT to understand; the files themselves have NO ACL PERMS. So when you move any of these file into a new folder in the same volume, MS claims the perms move with it (as above quote). Ask yourself this....how? There were no perms on the file in the first place to move across. This is actually incorrect and I just tested it now to confirm it. Let's say the destination folder you are moving the file to has perms to allow the everyone group modify rights only. Well since the file has no ACL directly, it inherits the ACL of the parent folder. This means the perms have changed from users modify (old folder) to everyone modify (new folder).
Notice the difference?? This time around, moving a file to another folder in the same volume actually has changed the perms, something MS says it doesn't do. Have I just found a mistake in MS documentation since 2000 lol??
Now look at the same scenario when using explicit permissions. If you set explicit permissions on a file within this folder (inheritance turned off) which, for example, denies users read access, it now creates A NEW ACL entry specifically for this file. Now when you move the file to a new location, it has an ACL entry directly related to it. In this case, moving a file to a new location in the same volume RETAINS its permissions (as MS claims)!
+1 Both are good answers, but yours is more to the point. I like your comment about how the 5GB file moves instantly. Good visual. – KCotreau – 2011-07-20T11:59:59.940
I tend to think that "no copy is happening" is the main reason why ACL isn't touched. – VVS – 2011-07-20T12:54:25.260
1There's no technical reason a change to the filesystem table shouldn't affect the corresponding ACL entry. I think this explanation is correct. But I also think it describes the effect, not the actual cause. The cause is ACL's own security model, which is per volume based. Move/copy operations between different volumes being understood as a transference of privileges and changes within the same volume as being privilege agnostic. By default, naturally. – A Dwarf – 2011-07-20T13:53:05.420
Plus this is the expected behavior. Users wouldn't expect that moving/copying a file from documents to pictures would all the sudden be denied Read access. Or that copying a file would all the sudden strip the file of encryption. I can think of 1000 other nightmare scenarios. . . – surfasb – 2011-07-20T18:37:51.540
And logically, the permissions to a file are set at creation. Notice when you change permissions on a folder that you have to propagate the permissions to all child object. That's why Windows sometimes throws up a dialog box as it changes all the child objects if there are a lot. – surfasb – 2011-07-20T18:39:42.320
@surfasb: If you copy the file it will inherit the target folder's permissions. – VVS – 2011-07-21T10:40:22.107
@Surfasb, Actually windows never "sometimes ask you to apply changes to child objects when propgating ACL changes. I think you are getting mixed up with taking ownership, when you do this it asks if you want to apply it to all sub folders. If you have 1000 files and say 200 folders below a folder and apply permissions at the parent it only applies it once and (again) is done almost instandtly. It is because it creates one new ACL entry (for this folder) but references this for all files and folders below. If however you turn "inheritence" off on a subfolder then it now creates another new ACL – Mucker – 2011-07-21T14:07:44.907
cont...for this new set of permissions on the folder. I also just realised something else, the MS article isn't exactly true, read my answer above for more info – Mucker – 2011-07-21T14:15:02.577
@Mucker: Actually, files do have their own ACLs. Each file has a security descriptor ID which is stored in their MFT entry. NTFS uses the SDID to eventually construct each object's DACL. These's ACLs are created when the file is created. Do a test. Create a new user account "John". Then give it write permission to "c:\user\My_account". But when you hit ok, the OS will try to modify all the child objects with the new permissions. Cancel it. John will have access to your root folder, but will not have write access to the child objects! That's because you are wrong. – surfasb – 2011-09-25T05:31:48.390
@surfasb, actually it is you who are wrong cause you hav misread my comment. You said "windows sometimes ask you to apply changes", I disagreed. I was 100% correct and you were wrong. When changing permissions it NEVER ASKS YOU, it automatically changes them. You are only ASKED when taking ownership of files (exactly what I said!). Your statement can't be proved about the files having ACL's. It is my GUESS that ACL aren't created but a reference is instead. When you see windows going through all the files after setting permisisons it COULD be changing ACL's (as you say) or it could be changing – Mucker – 2011-10-07T16:11:57.907
the reference (which means I am still correct). the results are exactly the same whether I am correct or you are about ACLs which is why it can't be proved either way. I still think they don't have ACLs because it would be innefficient. Look at it this way: Are you really telling me that if there are 1000 files under one folder windows creates 1000 identical ACLs for every file? Why not just do one ACL but get all files to reference it? – Mucker – 2011-10-07T16:13:12.070
@Mucker: If you read msdn, that's EXACTLY what the security descriptor does. It is a reference. Notice it says **every file and directory stores its own security descriptor in its own security attribute**. http://msdn.microsoft.com/en-us/library/ms995846.aspx
– surfasb – 2011-10-07T22:33:21.790@Surfasb, Haha, ony just saw your msg, thx for that link - you obviously didn't understand it cause it proves EXACTLY what I said. Here is a quote from it: In pre-Win2K NTFS, every file and directory stores its security descriptor in its own security attribute. In most cases, administrators apply the same security settings to an entire directory tree, which results in duplication of security descriptors across all the files and subdirectories to which the settings apply. This duplication can intensively utilize disk space in multiuser environments, such as – Mucker – 2011-12-13T01:43:29.043
Win2K Server Terminal Services and NT Server 4.0, Terminal Server Edition (WTS), in which security descriptors might contain entries for multiple accounts. NTFS5 optimizes disk utilization for security descriptors by using a central metadata file named $Secure to store only one instance of each security descriptor on a volume – Mucker – 2011-12-13T01:45:15.970
What does that say surfasb??? Read the bit that says it create ONE SECURITY DESCRIPTOR INSTANCE AND REFERENCES IT!!!! Isn't that what I said and you have disagreed???
ALso note the beginning of the quote saying that before win2k it DID CREATE DUPLICATES but this was inneficant!!! Hmmm, sound familiar?? exactly what I said again....I said it would inneficent to create multiple sec descriptors instead of one! You are WRONG and just shot yourself in the foot with that link lol – Mucker – 2011-12-13T01:48:05.737
The description ID you refer to in your last comment is exactly what I have said all along is the refernce. It is NOT AN ACL though. There is 1 ACL with say an ID of 58. Then all files references that ID of 58. Your argument has always been that the ACL is directly stored in the sec descriptor...which it isn't...because it would be inneficient. have fun. You can try worm you way out of it all you want but if you look back at all my comments they are clear and consisten about there being 1 ACL which is referenced. Yours are also very clear and consisten saying that ACL are stored with the file – Mucker – 2011-12-13T01:54:57.890
Which is wrong ;-) – Mucker – 2011-12-13T01:56:49.730
You are confusing the security descriptors and ACLs. Moving a file never updates the ACL. Thus it never updates the security descritor either. How and when does NTFS propagate inherited permissions? If they calculated as you said, how are hard links taken into account??Do you even know? http://support.microsoft.com/kb/320246. Also the obligatory Old New thing blog post. http://blogs.msdn.com/b/oldnewthing/archive/2006/08/24/717181.aspx
– surfasb – 2011-12-13T04:47:03.553@Surfasb...Go back and read my answer again...We have gone off topic a bit. I am NOT confusing anything. I was always talking about ACLs not sec descriptors. My case (as in my answer) states that ACLs are not duplicated, I said nothing about sec descriptors.
In your first comment back you said actually files do have ACLs -quote "Actually, files do have their own ACLs. " THAT IS WHAT YOU SAID. Then we kind of got lost on the tecnicalities. Don't try to use that excuse...if anyone got confsued it was you. My case clearly shows I was on about ACLs. You argued against that. – Mucker – 2011-12-14T00:45:50.587
So are you now saying the sec descriptor is the ACL? – Mucker – 2011-12-14T00:48:55.780
BTW here is yet ANOTHER quote from one of your own articles you linked to "NTFS5's use of general indexing lets files and directories that have the same security settings efficiently share security descriptors. The $SII index lets NTFS quickly look up a security descriptor in the $Secure file while performing security checks, and the $SDH index lets NTFS quickly determine whether a security descriptor being applied to a file or directory is already stored in the $Secure file and can be shared. " does this indicate that 1 ACL/sec descriptor can be used for multiple files?? YES, I think so! – Mucker – 2011-12-14T01:11:08.780
HOw much more proof do you need? I been consistent and even turned your own articles against you. that last one state exactly that there can be one ACL used for multiple files...which is EXACTLY what i have been saying and you have been against. You have said that files have their own ACLs...no they don't..they have IDs or something similar that REFERENCE a unique ACL/sec descriptor. Please in your next comment don't avoid this. Please prove this statement is incorret. – Mucker – 2011-12-14T01:14:21.477
@Mucker: Sorry, but your explanation is just plain wrong. Windows always stores the ACLs with the files, even if they're inherited. And from a file-system point of view, they always move with the file if the file is moved within the same volume. Depending on certain system settings, Windows Explorer will jump in and adjust the permissions after the move. But thats Explorer and has nothing to do with the file system. And worse: it depends on the Windows version and (as I already mentioned) certain system setting. See http://blogs.msdn.com/b/oldnewthing/archive/2006/08/24/717181.aspx
– Paul Groke – 2014-03-31T15:35:57.393