Eu acho que você, como eu, sempre viu caminhos da forma
\ !!! Importante \ ____ Novo ____ \ !!! Não exclua !!! \ Nº do pedido 98819-649-B de 30 de fevereiro de 1985 sobre a nomeação de Kozlov Ivan Aleksandrovich como chefe interino do departamento para acompanhar clientes VIP corporativos e organizar reuniões de negócios à margem.doc .
E, muitas vezes, abrir esse documento no Windows não funciona imediatamente. Alguém pratica a solução alternativa na forma de mapeamento de disco, alguém usa gerenciadores de arquivos que podem trabalhar com caminhos longos: Far Manager, Total Commander e similares. E muitos mais tristemente assistiram ao criar um script PS, que deu muito trabalho e funcionou em um ambiente de teste com um estrondo, em um ambiente de combate queixou-se impotente de uma tarefa impossível:
o caminho especificado, o nome do arquivo ou ambos são muito longos . O nome completo do arquivo deve ter menos de 260 caracteres e o nome do diretório deve ter menos de 248 caracteres.Como se viu, 260 caracteres são suficientes "não apenas para todos". Se você estiver interessado em ir além dos limites do que é permitido - peço gato.
Aqui estão apenas algumas das tristes conseqüências de limitar o comprimento de um caminho de arquivo:
Um pouco diferente do tópico, observo que, para a Replicação DFS, o problema considerado no artigo não é terrível e os arquivos com nomes longos viajam com êxito de servidor para servidor (a menos que, é claro, você tenha
feito tudo
corretamente do resto).
Também gostaria de chamar a atenção para o utilitário de
robocópia muito útil
que me ajudou mais de uma vez. Ela também não tem medo de caminhos longos e sabe muito. Portanto, se a tarefa se resumir a copiar / transferir dados do arquivo, você pode parar com isso. Se você precisar organizar com DACLs (listas de controle de acesso do sistema de arquivos), procure
subinacl . Apesar de sua idade considerável, mostrou excelentes resultados no Windows 2012 R2. Os métodos de aplicação são discutidos aqui.
Foi interessante para mim ensinar a trabalhar com o PowerShell de várias maneiras. Com ele quase como uma anedota barbada sobre Ivan Tsarevich e Vasilisa, a Bela.
Maneira rápida
Acesse o
Linux e não use o Windows 10/2016/2019 e ative a configuração de Diretiva de Grupo correspondente / clique em Registro. Não vou me debruçar sobre esse método em detalhes, porque já existem muitos artigos na rede sobre este tópico, por exemplo,
este .
Dado que na maioria das empresas existem muitas, para dizer o mínimo, não novas versões de sistemas operacionais, esse método é rápido apenas para escrever no papel, a menos que, é claro, você seja um daqueles sortudos que têm poucos sistemas legados e reinam no Windows 10/2016/2019 .
Longo caminho
Aqui, fazemos imediatamente uma reserva de que as alterações não afetarão o comportamento do Windows Explorer, mas possibilitaremos o uso de caminhos longos nos cmdlets do PowerShell, como Get-Item, Get-ChildItem, Remove-Item etc.
Primeiro, atualize o PowerShell. É feito um-dois-três.
- Estamos atualizando o .NET Framework para a versão não inferior a 4.5. O sistema operacional deve ter pelo menos o Windows 7 SP1 / 2008 R2. A versão atual pode ser baixada aqui , leia mais informações aqui .
- Baixe e instale o Windows Management Framework 5.1
- Reinicie o carro.
Pessoas que trabalham
duro podem executar as etapas descritas acima manualmente, com preguiça - com a ajuda do SCCM, políticas, scripts e
pesquisas de outras ferramentas de automação.
A versão atual do PowerShell pode ser encontrada na variável
$ PSVersionTable . Após a atualização, deve ser algo como isto:
Agora, ao usar os cmdlets
Get-ChildItem e similares, em vez do
caminho usual
, usaremos
LiteralPath .
O formato dos caminhos será um pouco diferente:
Get-ChildItem -LiteralPath "\\?\C:\Folder" Get-ChildItem -LiteralPath "\\?\UNC\ServerName\Share" Get-ChildItem -LiteralPath "\\?\UNC\192.168.0.10\Share"
Para a conveniência de converter caminhos do formato familiar para o formato
LiteralPath ,
você pode usar esta 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 você não pode usar caracteres curinga (
* ,
? , Etc.) ao especificar o parâmetro
LiteralPath .
Além do parâmetro
LiteralPath , na versão atualizada do PowerShell, o cmdlet
Get-ChildItem recebeu o parâmetro
Depth , com o qual você pode definir a profundidade do aninhamento para uma pesquisa recursiva, usei-o algumas vezes e fiquei satisfeito.
Agora você não pode ter medo de que seu script PS se desvie e não decida arquivos distantes. Por exemplo, essa abordagem me ajudou muito ao escrever um script para descartar o atributo "temporário" em arquivos nas pastas DFSR. Mas essa é outra história, que tentarei contar em outro artigo.
UPD 07/06/2019: Artigo prometidoEstou aguardando comentários interessantes e sugiro que faça uma pesquisa.
Links úteis:docs.microsoft.com/en-us/dotnet/api/microsoft.powershell.commands.contentcommandbase.literalpath?view=powershellsdk-1.1.0docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-5.1stackoverflow.com/questions/46308030/handling-path-too-long-exception-with-new-psdrive/46309524luisabreu.wordpress.com/2013/02/15/theliteralpath-parameter