Cortar / colar o arquivo entre pastas não mantém mais as permissões da pasta original

Question

Nas unidades NTFS, o comportamento costumava ser que, quando um arquivo era movido, ele retinha as permissões do arquivo original, se a movimentação fosse feita para uma pasta no mesmo volume.

Eu sei disso por experiência e pode ser visto aqui: link

Mas eu estava tentando mostrar esse comportamento hoje para um colega e isso simplesmente não funcionou. Cada vez que o arquivo simplesmente teria as permissões da nova pasta associada a ele.

Eu tentei em 3 máquinas diferentes e não funciona mais assim. Quando isso mudou? E não, a configuração do registro mencionada anteriormente não está definida.

Alguma ideia de quando isso mudou?

[Editar]

Apenas um exemplo para deixar mais claro

Suponha que eu tenha essas pastas na minha unidade C.

• C: \ Shared
  • \ Trabalhando
  • \ Final

E eu tenho quatro grupos:  - estagiários  - funcionários  - gerentes  - Staff (que tem os 3 anteriores como membros).

Agora, vamos considerar as permissões (simplificadas).

• C: \ Shared
  • não herda
  • permite explicitamente o controle total aos administradores
  • permite explicitamente modificar para gerentes
• C: \ Shared \ Working
  • Herda de Compartilhado
  • permite explicitamente modificar para funcionários
• C: \ Shared \ Final
  • Herda de Compartilhado
  • Permite explicitamente Ler para a equipe

Agora, vamos supor que eu tenha um arquivo na pasta Working, chamado Bullshit.doc.

Anteriormente, se o arquivo fosse movido (recortado / colado) da pasta Trabalho para a final, ele manteria as permissões originais, ou seja, os gerentes e a equipe poderiam modificar e os internos não teriam permissões.

Agora, quando eu tentar mover o Bullshit.doc, quando movido, simplesmente herdarei as permissões da pasta Final, ou seja, simplesmente perdoará que os estagiários não devem ter acesso.

Minha pergunta é: isso mudou, não foi? Ou eu estou ficando louco? Tenho 99% de certeza de que funcionou exatamente como descrito no KB.

Eu sei que tive problemas parecidos com isso no passado, quando usuários de nível superior moviam arquivos entre pastas (com um conjunto diferente de permissões) e depois reclamavam que os estagiários não conseguiam ler os arquivos. Eu tive que explicar mais de uma vez que cortar / colar não funcionaria, que eles precisam copiar / colar / excluir. Ele estava de volta no Windows 2003, com certeza, mas eu poderia ter pelo menos 2008 R2.

[Edit 2] Agora com fotos !!!

Ok, então decidi tentar replicar. Com os arquivos reais e não exemplos simples. Aqui está ...

Portanto, esta é a pasta de origem. Veja todas as permissões implícitas e a permissão explícita.

Agora,vamoscriarumarquivolá.Everifiqueaspermissões.

Horademoveroarquivoparaodestino.Apastaoriginaleraapenasumapastatemporária.Vamosverificaraspermissõesdapastadedestino.

Depoisdemoverapasta,vamosverificarsuaspermissões...

Hum ... não é o que eu esperava. Mesmo que fosse apenas um arquivo, pelo que eu juntei no KB acima, ele deve manter as permissões. E é assim que me lembro de se comportar.

Mas parece que mudou. E não consigo encontrar uma fonte oficial de quando isso aconteceu.

Isso me faz duvidar da minha sanidade.

    

Answer 1

O NTFS ainda está evoluindo e mudando. Eu acredito que as mudanças no manipulação de permissões herdadas apareceu pela primeira vez no Vista e tem mais evoluiu no Windows 7. A configuração do registro no seu link data do XP, então, tanto quanto eu sei, é ignorado em versões mais recentes.

Para entender o que acontece quando alguém copia / move um arquivo, é preciso primeiro entender a diferença entre permissões implícitas e explícitas.

As permissões implícitas são herdadas da pasta pai, por isso são armazenadas com a pasta pai. Eles não são armazenados com as crianças e, portanto, não são móvel / copiável. Em outras palavras, essas permissões só se aplicam quando a criança está em sua pasta pai, porque eles vêm do pai.

As permissões explícitas são fornecidas manualmente para a pasta / arquivo e são armazenadas em Listas de controle de acesso (ACL) como atributos NTFS. Eles podem ser considerados como pertencentes ao item e, em alguns casos, ser movido com ele se o sistema de arquivos de destino também for NTFS.

Algumas conseqüências dessa arquitetura NTFS são:

• Quando uma pasta / arquivo é copiado , novas entradas de destino são criadas nas tabelas NTFS da pasta de destino. Portanto, o arquivo copiado perderá todas as permissões explícitas e só herda de sua nova pasta pai.
• Quando um arquivo / pasta é movido dentro do mesmo volume , sua entrada NTFS é movida, completa com todos os atributos e permissões contidos. Portanto, ele manterá todas as permissões explícitas, mas perderá suas antigas permissões herdadas ganhando, em vez disso, aqueles de sua nova pasta pai.
• Quando uma pasta / arquivo é movido entre diferentes volumes , a movimentação é tratada como uma cópia e não reterá nenhuma das permissões originais. A única diferença da cópia é a fonte ser excluída quando a cópia estiver completa.
• Um arquivo / pasta que apenas herdou permissões, não tem permissão para se mover. Esse item sempre herdará suas permissões da pasta pai.
• Uma pasta / arquivo pode ser marcado como permissões não herdadas de seu pai. Nesse caso, todas as suas permissões são armazenadas como ACLs, significando como permissões explícitas.

Isso vai contra a documentação mais estabelecida, onde geralmente é alegado que quando uma pasta / arquivo é movido dentro do mesmo volume, ele reterá seu NTFS original permissões, implícitas e explícitas. Isso talvez tenha sido verdade em versões mais antigas do Windows mas foi verificado por mim e pelo cartaz como não sendo mais o caso de permissões implícitas no Windows 7 e no Windows 10.

Para um exemplo de regras de movimentação erroneamente documentadas, consulte o artigo Como as permissões de arquivo e pasta são tratadas ao mover ou copiar arquivos no Windows 2008 R2 e Windows 7 . Este artigo foi a fonte da minha discussão abaixo com o cartaz, onde descobrimos juntos as verdadeiras regras que governam a cópia e mover em NTFS.

    

Answer 2

Há um detalhe adicional importante para adicionar à explicação excelente e abrangente de harrymc, e esse detalhe acaba causando um comportamento de divisão, onde um movimento de arquivo às vezes se comporta no estilo 2003 e às vezes no estilo de 2008.

A maneira pela qual as movimentações intra-volume do NTFS foram atualizadas em 2008 / Vista e acima não é uma revisão completa, mas apenas a adição de uma segunda etapa em segundo plano.

Passo 1) A MFT está atualizada; o arquivo é movido e retém as permissões originais
(Assim como em 2003 / XP e anteriores. Movimentos nesses sistemas operacionais param nesta etapa.)

Etapa 2) As ACLs são atualizadas para descartar as permissões herdadas da pasta pai original e aplicar as permissões herdadas da nova pasta pai.
(Esta é a etapa adicional que o 2008 / Vista adicionou então os arquivos terão as permissões da pasta de destino.

No entanto, se o usuário que está realizando a movimentação tiver direitos Modificar e não tiver explicitamente a Alteração de Permissões correta, a etapa 2 falhará (mas não informará) , e você vai acabar com o comportamento old-school, então parece que as coisas estão de volta em 2003 novamente.

Nesse mesmo cenário, se alguém copiar o arquivo e, em seguida, excluir o original (da mesma forma que o sistema de arquivos manipula um movimento entre os volumes), tudo funcionará da maneira esperada.

Não há uma solução fácil: você concede aos usuários direitos Alterar Permissões para que a Etapa 2 possa ser bem-sucedida ou quaisquer arquivos movidos entre pastas de permissão diferentes na mesma o volume do servidor de arquivos manterá suas permissões originais até que sejam reimprimidas à força.