Acredito que, assim como eu, você também já deve ter visto caminhos como !!! Importante____Novo____!!! Não remover!!! Ordem nº 98819-649-B de 30 de fevereiro de 1985 sobre a nomeação de Kozlov Ivan Alexandrovich como interino do cargo de responsável por atender clientes corporativos VIP e organizar reuniões de negócios nos bastidores.doc.
E muitas vezes, abrir tal documento no Windows pode ser um desafio. Alguns utilizam soluções alternativas como o mapeamento de unidades, outros optam por gerenciadores de arquivos que lidam com caminhos longos: Far Manager, Total Commander e semelhantes. E muitos já observaram com tristeza como o script PS que criaram, no qual investiram bastante esforço e que funcionou perfeitamente no ambiente de testes, se mostrou impotente em produção, reclamando da tarefa impossível: O caminho, nome de arquivo ou ambos especificados são muito longos. O nome de arquivo totalmente qualificado deve ter menos de 260 caracteres e o nome do diretório deve ter menos de 248 caracteres.
Aparentemente, 260 caracteres não são suficientes "para todos". Se você está interessado em ultrapassar as fronteiras do permitido, siga em frente.
Aqui estão algumas das consequências tristes da limitação do comprimento do caminho do arquivo:
- em um servidor, existe uma pasta, por exemplo, D:DataSharedAccounting, que é compartilhada via SMB e montada para os usuários como a unidade de rede S; os usuários criam arquivos que não poderão ser lidos pelos administradores/script quando acessados localmente a partir do servidor, uma vez que o caminho absoluto acaba sendo mais longo que o caminho da rede;
- ;
- ;
- ao migrar dados de outros sistemas que têm restrições menos rigorosas sobre o comprimento do caminho, no novo ambiente, parte deles ficará inacessível sem algumas manobras.
- ;
- etc...
Um pequeno desvio do assunto, mas vale mencionar que para a Replicação DFS, o problema discutido no artigo não é um problema e arquivos com nomes longos viajam com sucesso de servidor para servidor (desde que você tenha feito tudo certo) ).
Gostaria de chamar a atenção para uma ferramenta muito útil que já me ajudou várias vezes . Ela também não teme caminhos longos e tem muitas funcionalidades. Portanto, se a tarefa for copiar/mover dados de arquivos, você pode optar por ela. Se precisar mexer com listas de controle de acesso no sistema de arquivos (DACL), olhe para . Apesar da idade avançada, apresentou-se muito bem no Windows 2012 R2. foram discutidas as formas de aplicação.
Estava interessado em ensinar a trabalhar com caminhos longos no PowerShell. É quase como na antiga piada sobre Ivan, o Czar, e Vasilisa, a Bela.
Uma maneira rápida
Mudar para Linux e não se preocupar com Windows 10/2016/2019 e habilitar a respectiva configuração de política de grupo/ajustar o registro. Não vou me aprofundar nesse método, pois já há muitos artigos na internet sobre isso, por exemplo, .
Considerando que na maioria das empresas existem muitas, digamos, versões não atuais dos sistemas operacionais, esse método é rápido apenas no papel, a menos que você seja um dos poucos sortudos que têm poucas sistemas legados e rodam Windows 10/2016/2019.
Uma maneira longa
De imediato, devemos esclarecer que as alterações não afetarão o comportamento do Explorer do Windows, mas permitirão o uso de caminhos longos nos cmdlets do PowerShell, como Get-Item, Get-ChildItem, Remove-Item e outros.
Primeiro, vamos atualizar o PowerShell. Isso é feito em um, dois, três.
- Atualizamos o .NET Framework para a versão não inferior a 4.5. O sistema operacional deve ser no mínimo Windows 7 SP1/2008 R2. A versão atual pode ser baixada , leia informações adicionais .
- e instalamos o Windows Management Framework 5.1
- Reinicie a máquina.
Os trabalhadores árduos podem realizar as etapas descritas acima manualmente, enquanto os preguiçosos podem usar SCCM, políticas, scripts e outros meios de automação.
A versão atual do PowerShell pode ser verificada na variável $PSVersionTable. Após a atualização, deve ficar assim:
Agora, ao usar os cmdlets Get-ChildItem e semelhantes, em vez do habitual Caminho vamos usar LiteralPath.
O formato dos caminhos será um pouco diferente:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Para facilitar a conversão de caminhos do formato habitual para o formato LiteralPath pode-se usar a seguinte função:
Function ConvertTo-LiteralPath
Param([parameter(Mandatory=$true, Position=0)][String]$Path)
If ($Path.Substring(0,2) -eq "") {Return ("?UNC" + $Path.Remove(0,1))}
Else {Return "?$Path"}
}
Observe que ao definir o parâmetro LiteralPath não se pode usar caracteres curinga (*, ? etc.).
Além do parâmetro LiteralPath, na versão atualizada do PowerShell, o cmdlet Get-ChildItem recebeu o parâmetro Depth, com o qual se pode definir a profundidade de aninhamento para busca recursiva. Eu usei algumas vezes e fiquei satisfeito.
Agora você não precisa mais temer que seu script PS se desvie do longo e árduo caminho e não reconheça arquivos distantes. Pessoalmente, esse método me ajudou muito ao escrever um script para remover o atributo 'temporário' de arquivos em pastas DFSR. Mas essa é uma outra história, que tentarei contar em um artigo futuro. Espero comentários interessantes de vocês e convido a participar da pesquisa.
Links úteis:
Apenas usuários registrados podem participar da pesquisa. , por favor.
O problema de caminhos longos ainda é relevante para você?
Sim
Era relevante, mas já resolvi
É um incômodo, mas não muito
Não pensei sobre isso, parece que tudo funciona
Não
Outro (especifique nos comentários)
155 usuários votaram. 25 usuários se abstiveram.
Fonte: habr.com
