Jefferson, 
10 de outubro de 2015, 
31/10/2015 – ATENÇÃO: Existe um problema sério com essa ferramenta. Leia os comentários.
Comparado com FAT32, NTFS é um sistema de arquivos superior em diversos aspectos. A maior resistência à corrupção das estruturas e o suporte a arquivos maiores que 4GB são as primeiras vantagens que me vem à mente e os motivos pelos quais eu raramente uso FAT32. É claro que o fato da maioria dos media players, NAS e outros “appliances” modernos também suportarem NTFS também ajuda.
Mas no dia-a-dia as permissões de acesso do NTFS são um aborrecimento constante.
OK. Não é exatamente culpa do NTFS. São as decisões aparentemente arbitrárias que as diversas versões do Windows posteriores ao XP tomam de que permissões dar a que arquivos e diretórios que me deixam maluco. Mas é mais fácil botar a culpa no NTFS, até mesmo porque só dá para resolver/contornar mexendo no sistema de arquivos. Eu não conheço nenhum modo de convencer o Windows Vista/7/8/10 a não ficar salpicando proibições de acesso em toda parte e isso atrapalha basicamente quando estou gerenciando backups de clientes.
Eu periodicamente faço backups completos na empresa do cliente e trago comigo. Em casa, rodo uma ferramenta para remover duplicatas (DoubleKiller) que compara com o backup existente e depois um batch para apagar diretórios vazios. Ambos falham silenciosamente ou com “Acesso Negado” quando esbarram em restrições que, para mim, nem deveriam estar lá.
Executar as ferramentas como administrador ou mexer nas permissões das pastas pela aba “Segurança” raramente surte o efeito desejado. Eu nunca consegui encontrar um jeito, pela interface gráfica do Windows, de resetar as permissões de arquivo para toda uma estrutura de pastas de uma vez só.
Pode ser incompetência minha, mas não estou sozinho. Este cara também passou por problema similar concluindo que tinha que usar a linha de comando do Windows para resetar as permissões e, melhor ainda, criou uma pequena GUI para faciltar o trabalho.
Meus problemas acabaram depois que passei a rodar ResetPermissions.exe no início de cada manutenção de backup.
A operação é muito simples. Basta dizer em que pasta você vai trabalhar e quais opções deseja aplicar. O programa mostra que comandos você teria que dar se fosse fazer “na munheca”, mas ele mesmo os aplica quando você clica em GO.
Eu percebi que para realmente me livrar das restrições eu tenho que marcar sempre (não é o default) “Take files owneship”. Isso pode não ser necessário no seu caso.
Você também pode usar esse programa para se livrar daquelas pastas e nomes como gde5y7hf5t4wefghytr4rgf56 que algumas atualizações do Windows saem espalhando pela raiz do seu HDD e que parecem ser “inapagáveis”. Resete as permissões das pastas que você poderá apagá-las normalmente.
Aliás, eu nunca comentei isso aqui mas o Treesize Free parece usar o icacls internamente porque a partir da árvore dele eu consigo apagar pastas que não podem ser apagadas pelo Explorer.
Treesize e´ um velho conhecido nosso. Mas esse reset e´ d+ mesmo!
Eu identifiquei um problema sério com o processo.
Apesar de você marcar a caixa “don’t follow links” o programa takeown segue os links e isso pode ser um desastre. Por exemplo, digamos que você fez uma cópia completa da partição de sistema de um cliente em um diretório qualquer (não precisa ser a raiz da unidade). Se essa cópia tiver links simbólicos para, por exemplo “Documents and Settings”, takeown pode seguir esse link e cair na pasta users do seu drive de sistema e mudar a propriedade de todas as pastas lá.
Isso aconteceu enquanto eu tratava o backup de um cliente no próprio computador do cliente. De repente, eu não conseguia salvar arquivos dentro da pasta Documentos do usuário que estava logado, porque não tinha permissão para isso. A coisa ficou tão bagunçada que eu tive que criar um novo perfil para o usuário. Até aí eu não tinha certeza do que havia acontecido.
Então eu trouxe o backup do cliente para tratar na minha máquina e repeti o processo. Por acaso eu vi na lista de pastas que rapidamente rolava na tela a palavra “Comodo”. Ora… o cliente não tinha o Comodo instalado na máquina. Quem tinha era eu. Dei CONTROL-C no processo e vi que Takeown estava processando várias pasta no drive K: (o drive do cliente) que não existiam no drive K:, mas existiam no meu drive C:. Aí eu cliquei no link “Arquivos de Programas” do drive do cliente e em vez de receber a conhecida mensagem “Acesso Negado” caí dentro de “Arquivos de Programas” do meu drive C: .
Então eu percebi que takeown precisa do parâmetro /SKIPSL para não seguir links simbólicos e isso não é feito pelo programa.
MUITO CUIDADO AO USAR ESSA FERRAMENTA.
Na falta de certeza, rode-a em um computador que tenha uma instalação descartável do Windows.
Esqueci de informar aqui que após explicar o problema para o desenvolvedor ele fez uma atualização do programa que resolve o problema.