Acho que você, assim como eu, já viu caminhos como esse mais de uma vez !!! Importante____Novo____!!! Não apagar!!! Despacho nº 98819-649-B datado de 30 de fevereiro de 1985 sobre a nomeação de Ivan Aleksandrovich Kozlov como chefe interino temporário do departamento de apoio a clientes VIP corporativos e organização de reuniões de negócios paralelas.doc.
E muitas vezes você não conseguirá abrir esse documento no Windows imediatamente. Algumas pessoas praticam soluções alternativas na forma de mapeamento de disco, outras usam gerenciadores de arquivos que podem trabalhar com caminhos longos: Far Manager, Total Commander e similares. E muitos mais assistiram com tristeza ao script PS que criaram, no qual muito trabalho foi investido e que funcionou com estrondo no ambiente de teste, em um ambiente de produção reclamando 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.
Acontece que 260 caracteres são suficientes “não apenas para todos”. Se você estiver interessado em ir além dos limites do permitido, consulte o gato.
Aqui estão apenas algumas das consequências infelizes da limitação do comprimento do caminho do arquivo:
- existe uma pasta no servidor, por exemplo, D:DataSharedAccounting, que é compartilhada via SMB e montada para os usuários como uma unidade de rede S; os usuários criam arquivos que os administradores/scripts não podem ler quando acessados localmente a partir do servidor, porque o caminho absoluto é maior que o caminho da rede;
- ;
- ;
- ao migrar dados de outros sistemas que possuem restrições menos rigorosas no comprimento do caminho, no novo ambiente alguns deles se tornarão inacessíveis sem dançar com um pandeiro;
- ;
- etc ...
Divergindo um pouco do tópico, observo que para a Replicação DFS o problema discutido no artigo não é terrível e os arquivos com nomes longos viajam com sucesso de servidor para servidor (se, é claro, todo o resto for ).
Também gostaria de chamar a atenção para um utilitário muito útil que me ajudou mais de uma vez . Ela também não tem medo de caminhos longos e pode fazer muito. Portanto, se a tarefa se resumir a copiar/transferir dados de arquivos, você pode parar por aí. Se você precisar pregar peças nas listas de controle de acesso do sistema de arquivos (DACLs), desvie o olhar . Apesar da idade avançada, teve um desempenho excelente no Windows 2012 R2. métodos de aplicação são considerados.
Eu estava interessado em ensinar como trabalhar com caminhos longos do PowerShell. Com ele é quase como uma piada barbuda sobre Ivan Tsarevich e Vasilisa, a Bela.
Maneira rápida
Mude para o Linux e não se preocupe com o Windows 10/2016/2019 e habilite a configuração de política de grupo apropriada/ajuste o registro. Não vou me alongar neste método em detalhes, porque... Já existem muitos artigos sobre este tema na Internet, por exemplo, .
Considerando que a maioria das empresas possui muitas, para dizer o mínimo, não as versões mais recentes de sistemas operacionais, esse método é rápido apenas para escrever no papel, a menos, é claro, que você seja um daqueles sortudos que possuem poucos sistemas legados e Windows 10 /2016/2019 reina supremo.
O longo caminho
Vamos fazer uma reserva aqui imediatamente que as mudanças não afetarão o comportamento do Windows Explorer, mas possibilitarão o uso de caminhos longos em cmdlets do PowerShell, como Get-Item, Get-ChildItem, Remove-Item, etc.
Primeiro, vamos atualizar o PowerShell. Já foi feito uma, duas, três vezes.
- Atualizamos o .NET Framework para uma versão não inferior a 4.5. O sistema operacional deve ser pelo menos Windows 7 SP1/2008 R2. Você pode baixar a versão atual , leia mais informações .
- e instale o Windows Management Framework 5.1
- Reinicializamos a máquina.
Pessoas trabalhadoras podem executar as etapas descritas acima manualmente, pessoas preguiçosas podem fazê-lo com a ajuda de SCCM, políticas, scripts e outras ferramentas de automação.
A versão atual do PowerShell pode ser encontrada na variável $ PSVersionTable. Após a atualização deverá ficar mais ou menos assim:
Agora, ao usar cmdlets Get-ChildItem e similares em vez do habitual Caminho nós vamos usar literalPath.
O formato do caminho será um pouco diferente:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Para a conveniência de converter caminhos do formato normal 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 ao definir o parâmetro literalPath Você não pode usar curingas (*, ? e assim por diante).
Além do parâmetro literalPath, na versão atualizada do cmdlet do PowerShell Get-ChildItem peguei o parâmetro Profundidade, com o qual você pode definir a profundidade de aninhamento para pesquisa recursiva, usei-o algumas vezes e fiquei satisfeito.
Agora você não precisa se preocupar com a possibilidade de seu script PS se desviar por um longo caminho espinhoso e não conseguir ver arquivos distantes. Por exemplo, essa abordagem me ajudou muito ao escrever um script para redefinir o atributo “temporário” de arquivos em pastas DFSR. Mas essa é outra história, que tentarei contar em outro artigo. Aguardo comentários interessantes seus e sugiro que você responda à pesquisa.
Links úteis:
Apenas usuários registrados podem participar da pesquisa. por favor
O problema dos caminhos longos é relevante para você?
-
Sim
-
Foi relevante, mas já decidido
-
Interfere, mas não muito
-
Não pensei nisso, tudo parece estar funcionando
-
Não
-
Outros (especifique nos comentários)
155 usuários votaram. 25 usuários se abstiveram.
Fonte: habr.com