Por que as permissões de arquivo são mantidas ao mover arquivos no mesmo volume?

Ocasionalmente, temos o problema de um arquivo ter permissões diferentes da pasta em que está.

Agora eu descobri que há um artigo da KB explicando o motivo por trás disso:

Por padrão, um objeto herda permissões do objeto pai, no momento da criação ou quando é copiado ou movido para a pasta pai. A única exceção a essa regra ocorre quando você move um objeto para uma pasta diferente no mesmo volume. Nesse caso, as permissões originais são mantidas.

Portanto, o usuário moveu o arquivo de uma pasta para outra e as permissões da pasta original foram mantidas.

Minha pergunta agora é: por que essa exceção existe? Qual é o raciocínio por trás disso?

Eu expliquei isso em uma postagem no blog http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/, mas também é explicado abaixo.

Quando um arquivo é copiado, ele precisa criar um novo arquivo e atribuir a ele um novo conjunto de permissões, para que ele obtenha as permissões da pasta pai, como você conhece.

Quando um arquivo é movido para outro volume, o que realmente acontece é que ele é copiado para o novo volume e o arquivo antigo é excluído. Portanto, o mesmo processo é repetido como acima, pois é um novo arquivo novamente e precisa de permissões.

Quando o arquivo é movido no mesmo volume, nada realmente acontece (no nível do disco). Apenas altera a localização do caminho lógico do arquivo. Os dados reais e o arquivo físico no disco não foram tocados ou alterados. Já reparou quando você move um arquivo de 5 GB para outra pasta na mesma unidade, isso é feito quase instantaneamente? É por isso que, porque ele realmente não foi movido, mas o ponteiro para onde o arquivo existe logicamente mudou. Como não foi modificado de forma alguma, as permissões também não são alteradas.

Essa é a razão para esse comportamento.

Edit: Algo que eu esqueci de mencionar ... O artigo da MS não é totalmente preciso. Citação MS:

Por padrão, um objeto herda permissões do objeto pai, no momento da criação ou quando é copiado ou movido para a pasta pai. A única exceção a essa regra ocorre quando você move um objeto para uma pasta diferente no mesmo volume. Nesse caso, as permissões originais são mantidas.

A citação acima se aplica apenas a objetos que recebem permissões de segundo EXPLICITAMENTE definidas (desative a herança). Como mencionado nos meus comentários, trata-se de manter as entradas da ACL tão eficientes quanto possível. Considere o seguinte exemplo:

Para manter a explicação simples, digamos que você tenha uma pasta definida para permitir que os usuários modifiquem apenas os direitos. Abaixo disso, existem milhares de arquivos e nenhum deles tem permissões explícitas definidas. Não é muito eficiente criar ACLs para cada arquivo, pois elas são exatamente as mesmas permissões, portanto, define uma entrada de ACL para a pasta. Este próximo bit é muito importante de entender; os arquivos em si não têm nenhum ACL PERMS. Portanto, quando você move qualquer um desses arquivos para uma nova pasta no mesmo volume, a MS alega que os privilégios se movem com ele (conforme a citação acima). Pergunte-se isso .... como? Não havia permissões no arquivo em primeiro lugar para se mover. Na verdade, isso está incorreto e eu apenas o testei agora para confirmar. Digamos que a pasta de destino para a qual você está movendo o arquivo tenha permissões para permitir que o grupo Todos modifique apenas os direitos. Bem, como o arquivo não possui ACL diretamente, ele herda a ACL da pasta pai. Isso significa que as permissões foram alteradas de usuários modificados (pasta antiga) para todos modificados (nova pasta).

Observe a diferença ?? Desta vez, mover um arquivo para outra pasta no mesmo volume realmente mudou as permissões, algo que a Microsoft diz que não faz. Acabei de encontrar um erro na documentação do MS desde 2000 lol ??

Agora observe o mesmo cenário ao usar permissões explícitas. Se você definir permissões explícitas em um arquivo dentro desta pasta (herança desativada) que, por exemplo, negue o acesso de leitura dos usuários, ele criará uma NOVA entrada da ACL especificamente para esse arquivo. Agora, quando você move o arquivo para um novo local, ele possui uma entrada da ACL diretamente relacionada a ele. Nesse caso, mover um arquivo para um novo local no mesmo volume RESTINA suas permissões (como afirma a MS)!

Quando você move arquivos no mesmo volume, tradicionalmente reorganiza seu sistema de arquivos . Alterar as permissões de arquivo no nível do diretório pode bloquear você desse arquivo no momento em que a operação de movimentação é concluída. Isso é indesejável se, por exemplo, você acabou de mover acidentalmente um arquivo para um sistema ou para uma pasta com permissões especiais de propriedade ou protegida. Não haveria maneira de corrigir o erro a não ser se apropriar do arquivo (se você tiver os privilégios) ou fazer logon com uma conta privilegiada. Considerando a operação normal do dia-a-dia de um computador, você pode descobrir que não tem controle sobre o seu sistema de arquivos.

Esse comportamento é comum na maioria dos sistemas operacionais (se não todos) que fazem uso da ACL. Garante operações normais do sistema de arquivos em um volume, tanto por usuários quanto por aplicativos.

Por outro lado, ao mover arquivos entre volumes, você tradicionalmente está dando um arquivo para controle por algo ou outra pessoa. Faz sentido, como você bem sabe, que o arquivo incorpore as permissões da pasta de destino, o que dará ao destino as permissões necessárias para reorganizar seu próprio sistema de arquivos como achar melhor.

Naturalmente, isso nem sempre é desejável. Por esse motivo, as operações de movimentação e cópia podem ser definidas com regras especiais de herança de permissão. Do mesmo artigo:

• Para preservar as permissões quando arquivos e pastas são copiados ou movidos, use o utilitário Xcopy.exe com a opção / O ou / X. As permissões originais do objeto serão adicionadas às permissões herdáveis ​​no novo local.

• Para adicionar permissões originais de um objeto a permissões herdáveis ​​quando você copiar ou mover um objeto, use o utilitário Xcopy.exe com as opções –O e –X.

OK Esta é a verdadeira realidade. Primeiro - estamos falando de um único PC ou servidor? Suponho que estamos falando de um servidor. Então .... como administrador da Wintel da empresa A, você cria um sistema de arquivos em uma unidade de rede em seu novo servidor. Você o baseia em departamentos, ou seja, cada departamento tem uma pasta e cada pasta tem sua própria ACL exclusiva devido a problemas de confidencialidade, como provavelmente é a norma - sim? Portanto, se você deseja mover um arquivo para a pasta de outro departamento, por que diabos NÃO deseja que ele herde os privilégios de sua nova pasta? O que eu quero dizer é ... por que ter um sistema de arquivos baseado em permissões, se você não vai usá-lo? Posso dar um exemplo da vida real em que é importante que os arquivos / pastas movidos sempre herdem a ACL da pasta pai, é só me perguntar.

Mover arquivos dentro de um volume ou movê-los do volume X para o volume Y ... qual é a diferença essencial? Você está movendo a localização de alguns arquivos - em diferentes volumes ou não faz pouca diferença em um ambiente corporativo, tanto quanto eu posso ver. A verdadeira razão pela qual uma inclui herança por padrão e a outra ainda não foi mencionada por Mucker - que é "eficiência". Arrastar e soltar arquivos dentro de um volume apenas altera a entrada Índice - os arquivos não são movidos e as informações da ACL são deixadas em paz. Faz para uma operação simples. Quando os arquivos são movidos entre volumes, no entanto, os arquivos e suas ACLs precisam ser redefinidos; portanto, fazê-lo corretamente e incluir a herança faz sentido, pois não incorre em uma sobrecarga evitável.

Não consigo entender por que a Microsoft não resolve esse problema. Seria muito difícil incluir uma caixa de diálogo como parte do arrastar e soltar do Explorer? Algo como "Você moveu os arquivos para um local com direitos de acesso diferentes. Deseja herdar as permissões da nova pasta pai? S ou N?"

Atenciosamente, Stonegiant