File System Permissions on copy or move


I was recently asked by a very technical and very sharp friend of mine about the symantics of permissions on copy.

I figured if he needed some guidance on how this works then there must be a ton of other developers who could use a refresher so here goes:

There are alot of reasons that a developer or QA engineer must use copy or move to get their applications running for test or even for production.  The problem is that the same old processes that worked so many times before can often mask a misconception or two that arise as “bugs” when the moons do not align to make the old process function as expected.  Case in point.  You want to deploy a web application which has notoriously particular permissions requirements.  If copy has always worked in  the past, but on the new server you are getting strange permissions then you might be forgetting some of the rules.

The first thing to take into account is whether this is this a move within the same volume (nothing fancy) or a move across volumes (maybe obscured by DFS) or even just a plain old copy (often the case).

A move within volumes would mean you should have the permissions preserved. A move across volumes is actually a copy and a delete combined and means you are just getting the permissions of the target folder which is by design and this is also the behavior of a copy unless you use something like scopy which preserves permissions.

If a copy in the past has preserved permissions and you didn’t use scopy (very handy by the way) then either there is a setting in Windows that I am unaware of (please enlighten me) or you got lucky in the past and the target folder permissions were what you expected.

Usually file permissions and especially the semantics of permissions on copy vs. move are the domain of network types.  In many cases it helps alot to be a mongrel from both worlds.