Lo he explicado en una publicación de blog http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ pero También se explica a continuación.
Cuando se copia un archivo, tiene que crear un archivo nuevo y asignarle un nuevo conjunto de permisos, de modo que obtenga los permisos de la carpeta principal como ya sabe.
Cuando un archivo se mueve a otro volumen, lo que realmente sucede es que se copia al nuevo volumen y se elimina el archivo anterior. Entonces, el mismo proceso se repite como anteriormente, ya que es un archivo nuevo nuevamente y necesita permisos establecidos.
Cuando el archivo se mueve dentro del mismo volumen, realmente no sucede nada (a nivel de disco). Simplemente cambia la ubicación de la ruta lógica del archivo. Los datos reales y el archivo físico en el disco no se han tocado ni cambiado. ¿Alguna vez notó que cuando mueve un archivo de 5GB a otra carpeta en el mismo disco, se hace casi al instante? Es por eso, porque en realidad no se ha movido, pero el puntero a donde existe lógicamente el archivo ha cambiado. Como no se modificó de ninguna manera, los permisos tampoco cambian.
Esta es la razón de este comportamiento.
Editar: Algo que olvidé mencionar ... El artículo de MS no es del todo exacto. MS cita:
De forma predeterminada, un objeto hereda los permisos de su objeto primario, ya sea en el momento de la creación o cuando se copia o se mueve a su carpeta principal. La única excepción a esta regla ocurre cuando mueve un objeto a una carpeta diferente en el mismo volumen. En este caso, se retienen los permisos originales.
La cita anterior solo se aplica a los objetos a los que se les han otorgado permisos de sec definidos EXPLÍCITAMENTE (desactivar la herencia). Como mencioné en mis comentarios, se trata de mantener las entradas de ACL lo más eficientes posible. Considere el siguiente ejemplo:
Para simplificar la explicación, supongamos que tiene una carpeta configurada para permitir que los usuarios solo modifiquen los derechos. Debajo de esto, hay miles de archivos y ninguno de ellos tiene permisos explícitos establecidos. No es muy eficiente crear ACL para cada archivo, ya que son exactamente los mismos permisos, por lo que establece UNA entrada de ACL para la carpeta. El siguiente bit es muy IMPORTANTE de entender; los archivos mismos NO TIENEN ACL PERMS. Entonces, cuando mueve cualquiera de estos archivos a una nueva carpeta en el mismo volumen, MS afirma que las permisos se mueven con él (como se cita arriba). Pregúntate esto ... ¿cómo? No había permisos en el archivo en primer lugar para moverse. Esto es realmente incorrecto y lo acabo de probar ahora para confirmarlo. Digamos que la carpeta de destino a la que está moviendo el archivo tiene permisos para permitir que el grupo de todos modifique los derechos solamente. Bueno, dado que el archivo no tiene ACL directamente, hereda la ACL de la carpeta principal. Esto significa que los permisos han cambiado de modificación de usuarios (carpeta antigua) a modificación de todos (carpeta nueva).
¿Nota la diferencia? Esta vez, mover un archivo a otra carpeta en el mismo volumen realmente ha cambiado las permanentes, algo que MS dice que no hace. ¿Acabo de encontrar un error en la documentación de MS desde 2000 lol ??
Ahora observe el mismo escenario cuando use permisos explícitos. Si establece permisos explícitos en un archivo dentro de esta carpeta (herencia desactivada) que, por ejemplo, niega el acceso de lectura de los usuarios, ahora crea una NUEVA entrada de ACL específicamente para este archivo. Ahora, cuando mueve el archivo a una nueva ubicación, tiene una entrada de ACL directamente relacionada con él. En este caso, mover un archivo a una nueva ubicación en el mismo volumen ¡CONSERVA sus permisos (como afirma MS)!