The MoveSecurityAttributes policy affects only how Explorer recalculates ACLs when a file is moved; everybody else is on their own

A customer reported that even though they were deploying Move­Security­Attributes policy to all their machines, it wasn't working everywhere. "It works fine with the GUI but does not work (i.e., has no effect) when using the Move command at the command prompt."

That's right.

The Move­Security­Attributes policy applies to Explorer's file copy engine, the thing that kicks in when you call SHFile­Operation or use the IFile­Operation interface.

The command prompt doesn't use either of those functions. It just calls the Move­File­Ex function directly. And that function doesn't respect UI policy because it's not a UI function.

The KB article does say this when it finishes talking about the default behavior and starts talking about the policy:

By default…

You can modify how Windows Explorer handles permissions when objects are copied or moved…

(Emphasis mine.)

The article points out that the technique applies only to Windows Explorer. Mind you, it's not underlined or anything, so somebody in a hurry is like to miss out on that detail.

So here's a blog entry to make it more clear.

Comments (13)
  1. David-T says:

    It does seem a bit odd that a security policy is implemented in the User Interface…

    [It's not a security policy. It's a UI policy. It's under the Explorer node and controls how Explorer handles ACLs when files are moved in the UI. -Raymond]
  2. Ben Voigt says:

    That KB article has quite a number of problems with it.  For example, nearly every item in the bulleted list is not a rule at all, but a convention (so-called "canonical order" for ACE entries), the actual rule is that ACE entries that appear earlier in the ACL take precedence.

    But the article actually does show that programs other than Windows Explorer use a different method for controlling ACL preservation, using xcopy command-line arguments as an example.

  3. DWalker says:

    The term "Windows Explorer" technically means one thing, but to users, it means "Windows".  I would consider a CMD prompt, that was opened by Windows, to be running "under" Windows Explorer.  It displays itself in a window, after all.  So, a CMD prompt's command line interface is "part" of Windows Explorer.

    The article, while technically correct, is certainly not clear.  Thanks for the blog entry, but "someone" ought add a heap of clarifyin' to the MSDN article.

  4. Yukkuri says:

    @DWalker Normally I am sympathetic to pleas for better documentation, but people that don't understand Windows well enough to know the difference between the command prompt and explorer SHOULD NOT BE people employed to manage them for their entire enterprise.

  5. Eddie says:


    Employers don't know the difference between the command prompt and Explorer either.  OK, so they hire a system administrator to handle that.  One small problem though, the sys admin who is not qualified for the job convinces the employer that he is awesome.

    There really isn't a solution for this.

  6. Cesar says:

    Windows Explorer was bolted on over the real filesystem, and it shows. If Windows were designed from scratch, the Windows Explorer layer would be the only way to access the filesystem, and there would be no confusion caused by programs trying to manipulate the real filesystem behind it directly. But the real filesystem came first, and Microsoft can't remove it from the API.

    To make things even worse, from what I have read in this blog you are NOT supposed to use Windows Explorer APIs on services; you are supposed to always go directly through the filesystem API. So Microsoft can't even tell everyone "always use the Windows Explorer APIs" (say you are writing a library which can be used by both services and user-facing applications). And, of course, there's the small detail that plenty of applications or libraries are ported from Unix, or written by developers who are more used to the Unix way of doing things, which is more similar to the real filesystem API and completely different from the Windows Explorer APIs…

  7. Joshua says:

    @Cesar: Believe it or not, I know how to invert the whole thing to make it work the other way around. The ramifications of the system change are nasty as the root problems of COM would have to be really addressed (shell namespace COM extensions would have to /not care/ what threading model they were launched in). It sounds like a crazy impossible thing, but the whole set is in fact achievable. You will run screaming in horror when I tell you that everything you think you know would have to change right down to how the loader itself works. But it's all possible. FUSE is my witness; we can invert the stack.

    But do you really want the kinds of guys who feel most the need to make shell namespace extensions known for their instability writing code that runs at such a level where one screwup can bring down every process in the system so even safe mode doesn't boot? Probably not.

  8. Gabe says:

    Cesar: If you think that MS would merge Explorer and filesystem APIs if they were designing the system from scratch, think again.

    Over 30 years ago Apple designed a system from scratch where the graphical shell (Finder) was expected to be the only way a user would interact with the filesystem. The system had no command line (nor even a built-in way to create one). It was so all–encompassing that the user would never even know that the ":" was used as the path separator unless they attempted to type the character into a filename.

    Yet even Apple implemented the system with a filesystem layer and Finder as an abstraction on top of that.

    If even a tightly-integrated system like Macintosh that was designed with no thought towards compatibility with any other system had separate filesystem APIs, why would anybody see the need to design such a system today?

  9. xpclient says:

    There was also a ForceCopyACLwithFile policy that got broken starting with Vista.

  10. dave says:

    >If Windows were designed from scratch, the Windows Explorer layer would be the only way to access the filesystem,

    So every program would have to call Windows Explorer to open a file?  (Even an internal temporary file of no interest to the user)

    And if a program wanted to move a file, it would have to have Explorer do it.

    And if a program wanted to set an ACL on a file, it would have to have Explorer do it.

    That seems a little… inefficient.

    So we make an exception that programs can issue file system API calls directly?

    That's exactly the current situation.

  11. Kevin says:


    What Cesar is proposing is reminiscent of the microkernel idea: You have a small kernel for handling credentials and other stuff that absolutely *has* to run in kernel mode, and everything else lives in userspace, including most of the filesystem code.

  12. DWalker says:

    @Yukkuri:  I agree that "people employed to manage them [Windows computers] for their entire enterprise" would, or should, be fine with the explanation in this blog post.  And, also, clarifying the MSDN article would help everyone!  

    Computers are hard.  Some of us are paid to handle that complexity.  :-)

  13. Yukkuri says:

    @Eddie Why do you have to destroy my happy fantasy word? :(

Comments are closed.

Skip to main content