Cut/paste file between folders no longer keep the original folder permissions

Question

In NTFS drives, the behavior used to be that, when a file was moved, it would retain the permissions of the original file, if the move was made to a folder on the same volume.

I know this by experience and it can be seen here: https://support.microsoft.com/en-us/kb/310316

But I was trying to show this behavior today to a colleague and it just didn't work. Every single time the file would simply have the permissions from the new folder associated to it.

I've tried in 3 different machines and it no longer works like that. When did it change? And no, the registry setting mentioned previously isn't set.

Any idea when this changed?

[Edit]

Just an example to make it more clear

Suppose I have these folders, in my C drive.

• C:\Shared
  • \Working
  • \Final

And I have four groups: - Interns - Employees - Managers - Staff (that has the previous 3 as members).

Now, let's consider the permissions (simplified).

• C:\Shared
  • Does not inherit
  • Explicitly allows Total Control to Admins
  • Explicitly allows Modify to Managers
• C:\Shared\Working
  • Inherits from Shared
  • Explicitly allows Modify to Employees
• C:\Shared\Final
  • Inherits from Shared
  • Explicitly allows Read to Staff

Now, let's supposed I have a file in the Working folder, called Bullshit.doc.

Previously, if the file was moved (cut/pasted) from the Working to the Final folder, it would retain the original permissions, i.e., Managers and Staff could Modify and Interns would have no permissions.

Now, when I try moving the Bullshit.doc, when moved, will simply inherit the permissions from the Final folder, i.e., it simply forgives that Interns shouldn't have access.

My question is: this changed, didn't it? Or I am going crazy? I'm 99% sure that it worked just like described in the KB.

I know I had problems similar to this in the past, when upper level users moved files between folders (with different set of permissions) and then complained that the interns couldn't read the files. I had to explain more than once that cut/paste wouldn't work, that they need to copy/paste/delete. It was back on Windows 2003 for sure, but I could be at least 2008 R2.

[Edit 2] Now with pictures!!!

Ok, so I decided to try and replicate. With the actual files and not simple examples. Here it is...

So this is the source folder. See all the implicit permissions and the one explicit permission.

Now, let's create a file in there. And check it permissions.

Time to move the file to the destination. The original folder was just a temp folder. Let's check the destination folder permissions.

After moving the folder, let's check its permissions...

Hum... not what I'd expect it. Even if it was just a file, from what I gathered in the KB above, it should keep the permissions. And that's how I remember it behaving.

But it seems it changed. And I can't find an official source of when it happened.

This makes makes me doubt my sanity.

Answer 1

NTFS is still evolving and changing. I believe that the changes to the handling of inherited permissions has first appeared in Vista and has further evolved in Windows 7. The registry setting in your link dates from XP, so as far as I know it is ignored in newer versions.

To understand what happens when one copies/moves a file, one must first understand the difference between implicit and explicit permissions.

Implicit permissions are inherited from the parent folder, so are stored with the parent folder. They are not stored with the children and therefore are not movable/copiable. In other words, these permissions only apply while the child is in its parent folder, because they come from the parent.

Explicit permissions are given manually to the folder/file and are stored in Access Control Lists (ACL) as NTFS attributes. They can be considered as belonging to the item and may in some cases be moved with it if the target file-system is also NTFS.

Some consequences of this NTFS architecture are :

• When a folder/file is copied, new target entries are created in the NTFS tables of the target folder. Therefore the copied file will lose all explicit permissions, and will only inherit from its new parent folder.
• When a file/folder is moved inside the same volume, its NTFS entry is moved, complete with all contained attributes and permissions. Therefore it will retain all explicit permissions, but will lose its old inherited permissions, gaining instead those of its new parent folder.
• When a folder/file is moved between different volumes, the move is treated as a copy and will retain none of the original permissions. The only difference from copy is by the source being deleted when the copy is complete.
• A file/folder that only has inherited permissions, has no permissions to move. Such an item will always inherit its permissions from the parent folder.
• A folder/file may be marked as non-inheriting permissions from its parent. In that case, all its permissions are stored with it as ACLs, meaning as explicit permissions.

This goes against most established documentation, where it is usually claimed that when a folder/file is moved a inside the same volume, it will retain its original NTFS permissions, both implicit and explicit. This was maybe once true in older versions of Windows, but was verified by myself and by the poster as no longer being the case for implicit permissions in Windows 7 and Windows 10.

For an example of erroneously-documented move rules, see the article How file and folder permissions are handled while moving or copying files on Windows 2008 R2 and Windows 7. This article was the source of my discussion below with the poster, where we discovered together the true rules that govern copy and move in NTFS.

Answer 2

There is an additional important detail to add to harrymc's excellent and comprehensive explanation, and this detail ends up causing split behaviour, where a file move sometimes behaves in the 2003-style and sometimes in the 2008-style.

The manner in which NTFS intra-volume moves was updated in 2008/Vista and above is not a complete overhaul, but just adding a second step in the background.

Step 1) MFT is updated; the file is moved and retains original permissions
(Just like in 2003/XP and earlier. Moves on those OSes stop at this step.)

Step 2) ACLs are updated to drop the original parent folder's inherited permissions and apply the new parent folder's inherited permissions.
(This is the additional step that 2008/Vista added so files will have the target folder's permissions.)

However, if the user who is performing the move has Modify rights and does not explicitly have the Change Permissions right, step 2 will fail (but not tell you), and you will end up with the old-school behavior so it seems like things are back in 2003 again.

In this same scenario, if someone copies the file and then deletes the original (the same way the file system handles a move between volumes), everything works the way you would expect it to.

There isn't any graceful solution - you either give users Change Permissions rights so Step 2 can succeed, or any files moved between different-permission folders on the same file server volume will retain their original permissions until they are forcibly re-propagated.