Wait, so does moving a file recalculate inherited permissions or doesn’t it?

A customer had a question about whether moving a file recalculated inherited permissions. They found that on their Windows Server 2008 R2 machine, if they moved a file between directories with different inheritable ACEs, then the security descriptor is recalculated to match the destination folder, if they perform the move from the machine itself. The same thing happens if they go to a machine running Windows 7, However, if they repeat the experiment from a machine running Windows XP or Windows Server 2003, then the security descriptor is preserved across the move.

The customer is confused. Why does the behavior change based on the version of Windows running on the client, even though the files themselves are kept on the same server?

The explanation is given in a few places:

Even with these explanations, the customer remained confused.

"Why does the permission depend on the operating system running on the client? The files are on the server, so regardless of the client operating system, it should be following the rules which apply to the server, right?"

There are two different operations here.

Suppose I told you, "When you buy clothes from the store, it will have the store sticker on it. You must remove the sticker yourself, and you should also wash the clothes before wearing it the first time, because the store puts powder in the bag to keep the clothes from getting moldy."

You then say, "That is not true. When I go to my closet to get clothes I recently bought from the store, the store stickers are already gone, and there is no powder."

That's because you live with your parents, and your mother takes your clothes, removes the stickers, washes the clothes, and then hangs them up in your closet.

The underlying file system "move" operation preserves the ACLs from the source.

On the other hand, if you use Explorer to move the files, then you are not using the underlying file system "move" operation directly. Your mother is moving the files. And when mother Explorer moves the files, she also edits the ACLs based on the nature of the source and destination folders, as described in the aforementioned Knowledge Base articles. Furthermore, different versions of mother Explorer edit the ACLs in different ways.

That is why the behavior is dependent upon the client operating system. When you move the file from a client machine connected to the server, the client machine asks the server to move the files (which preserve the ACLs since that's what the low-level "move" operation does), and then the client machine goes back in and edits the ACLs in a client-specific way.

It is therefore the client operating system which controls how the ACL editing is performed, because it is the client operating system which is editing the ACLs.

Comments (15)
  1. Joshua says:

    Lovely. About as much fun as explaining to a senior engineer that rename() library function is not atomic across filesystem boundaries.

  2. alegr1 says:

    Aren't you confusing things?

    According to the KB 2617058 (and my experiences), the security attributes were not recalculated in Windows 7 RTM, and the KB provided a hotfix for this problem. While this worked in XP and 2003.

    It's because the folks at MS had rewritten the Explorer completely, and forgot a few things in the process. Such as Alt+Enter in the folder tree.

    He-who-should-not-be-named will provide you with a list of grievances promptly.

  3. DWalker says:

    KB article 2617058 is confusing.

    It says "This issue occurs because the MoveSecurityAttributes registry subkey is not supported in Windows 7, in Windows Vista, in Windows Server 2008 or in Windows Server 2008 R2."  

    That sounds pretty straightforward.  Something is happening, and this sentence explains why.  

    But wait, there's more!  The article then goes on to say "To resolve this issue, install the following hotfix package on the affected computer."  Wait, to resolve this issue?  If something is not supported in these operating systems, I wouldn't call that an "issue" that can be "resolved" — I would call it a design feature.

    The article should say something like "to change this behavior…".  

    The first thing I quoted should not say "is not supported", it should say "… is not supported … unless this hotfix is installed" or "was incorrectly not supported".  

    The writers of the KB article don't know how to clearly explain things, IMO.

  4. alegr1 says:


    MoveSecurityAttributes defaults to 1. XP/2003 would read a registry value to override that.

    Vista+ didn't read the registry override, or ignored it, which was a design flaw (missed during the rewrite). Maybe the whole function to recalculate the ACLs was missing.

  5. Nick says:

    I'm sure there's a joke in here between Mother Explorer and Mother from Alien (computer of the Nostromo), but I'm not really seeing it.

    It does seem a questionable design to have the client file manager go muck around with permission rules on another machine, especially if the rules governing such behavior aren't fixed.  I suppose by allowing Explorer to direct the process you do eliminate some issues with third-party SMB filesystems (NAS, samba, etc) each doing things their own different way.  But of course, if Microsoft themselves then turn around and introduce the same problem in a different way then any benefit is eliminated.

    [Users asked for this feature because they kept complaining that the old rules were non-intuitive. "If I move a file from a private folder to a public folder, I expect the file to become public." -Raymond]
  6. Destroyer says:

    @Aneurin – This is absolutely not wrong. It seems obvious to me that the client is responsible for calculating the ACLs of the files, the user is sitting on the client machine, the server doesn't know what is going on at the client machine, offloading that to the server would be insane. How would the server know what volumes/mappings those files reside on inside the client. What if the client was accessing files via some sort of storage virtualization. What if files on the server resided on some multi-TB SAN volume but they were seperate drive mappings to the client OS. The customer would be even more confused because the customer probably has no idea about what drives or where the files are stored on the server, so the recalculation would be impossible for the end-user to predict.

    I could go on, but I think you might get the picture.

  7. Mark Y says:

    Did I ever mention that your analogies are truly precious?  I love 'em.

  8. Aneurin Price says:

    I had a long flame here, but in the interests of not being a *total* arsehole I'm going to skip it, and say this instead:

    I don't understand why you have to be so obnoxious to/about people like this. The behaviour of the software you're describing is clearly wrong. You'll come up with some reason it has to be that way because of such-and-such, which will also be clearly wrong, and you'll explain *that* away because of so-and-so, which will also be clearly wrong, until eventually it boils down to one erroneous hidden assumption or bad choice in a trade-off twenty-five years ago, but of course you'd never get to the point of admitting that.

    The customer was expecting something sensible, and Windows wasn't giving it. You'll never admit that, and you'll choose to mock instead, but that's because you *really are* an arsehole, an abusive, arrogant arsehole.

    I've been reading this blog for years because there is a lot of valuable knowledge here, dispensed in small nuggets, if you can dig it out of the snide attacks on people who aren't there to defend themselves.

    I can't take that any more though and I have to give up. I just want you to know Raymond, from the bottom of my heart, that I think you are a terrible human being, and I genuinely pity those poor souls who have to work with you.

  9. xpclient says:

    Both ForceCopyAclwithFile and MoveSecurityAttributes broke in Vista (or were broken By Design). KB2617058 fixed MoveSecurityAttributes for Vista/7 quite late (2012 :O). These days some hotfixes shipped late in the lifecycle for "legacy" platforms don't get carried over to the next OS codebase so I don't know about Windows 8. ForceCopyAclwithFile remains broken on all OSes after XP.

  10. DWalker says:

    @Alegr1:  What you say may be perfectly true; my complaint was the wording in the KB article.  It explains that something is not supported.  Then it says "to resolve this issue".

    The phrase "This issue occurs because the MoveSecurityAttributes registry subkey is not supported in Windows 7, in Windows Vista, in Windows Server 2008 or in Windows Server 2008 R2" should instead say "This issue occurs because the MoveSecurityAttributes registry subkey was not originally supported in Windows 7, in Windows Vista, in Windows Server 2008 or in Windows Server 2008 R2.  To add this support, install this hotfix." or something like that.  Notice the added phrase "was not originally supported" instead of saying "is not supported".

    Saying that something "*is* not supported" (emphasis mine) and then saying this issue can be fixed, is a strange choice of phrases.  :-)

  11. Neil says:

    I want to blame this on a design flaw in ACLs, to wit, copying the ACL from the parent causes this unintuitive behaviour. That's not to say that at the time there weren't sound engineering decisions for choosing that behaviour.

  12. Marc K says:

    The KB2617058 article is surprising.  I have a vague memory of reading something long ago that claimed Windows Vista or 7 changed to copy file semantics for file moves on the same volume.  Even with the hotfix installed and setting MoveSecurityAttributes to 1, I am not able to get a Vista or 7 machine to revert to the XP behavior.  On my XP machine, the same test produces the expected results depending on if MoveSecurityAttributes is 0 or 1.

  13. alegr1 says:


    By default, ACL stays the same, and on the same place. The move operation only moves the hardlink from one directory to another, the file record stays the same. Same behavior in Unix/Linux, too.

    @Marc K:

    Default XP behavior corresponds to MoveSecurityAttribytes=0.

  14. JamesNT says:

    Having the client calculate the ACL's makes perfect sense since the client is the one making the request.  Also, the behavior Mr. Chen describes makes perfect sense along with his description of moving a file from a private to a public folder.

    I fail to see the problem, here.


  15. Marc K says:


    The default XP behavior corresponds to MoveSecurityAttribytes=1.  That's why KB310316 instructs you to add MoveSecurityAttribytes as 0 if you want non-default behavior.

Comments are closed.

Skip to main content