Creo que ti, coma min, viches camiños coma este máis dunha vez !!! Importante____Novo____!!! Non borrar!!! Orde n.o 98819-649-B do 30 de febreiro de 1985 sobre o nomeamento de Ivan Aleksandrovich Kozlov como xefe interino temporal do departamento para apoiar clientes VIP corporativos e organizar reunións de negocios á marxe.doc.
E moitas veces non poderás abrir un documento deste tipo en Windows de inmediato. Algunhas persoas practican unha solución alternativa en forma de mapeo de discos, outras usan xestores de ficheiros que poden traballar con camiños longos: Far Manager, Total Commander e similares. E moitos máis viron con tristeza como o guión de PS que crearon, no que se investiu moito traballo e que funcionou a golpe no ambiente de probas, nun ambiente de produción queixábase impotentemente dunha tarefa imposible: O camiño especificado, o nome do ficheiro ou ambos son demasiado longos. O nome do ficheiro totalmente cualificado debe ter menos de 260 caracteres e o nome do directorio debe ter menos de 248 caracteres.
Polo que se ve, 260 caracteres son suficientes "non só para todos". Se estás interesado en ir máis aló dos límites do permitido, consulta o gato.
Aquí están só algunhas das desafortunadas consecuencias de limitar a lonxitude da ruta do ficheiro:
- hai un cartafol no servidor, por exemplo, D:DataSharedAccounting, que se comparte a través de SMB e se monta aos usuarios como unha unidade de rede S; os usuarios crean ficheiros que os administradores/scripts non poden ler cando se acceden localmente desde o servidor, porque o camiño absoluto é máis longo que o camiño da rede;
- ;
- ;
- ao migrar datos doutros sistemas que teñen restricións menos rigorosas na lonxitude do camiño, no novo entorno algúns deles pasarán a ser inaccesibles sen bailar cunha pandeireta;
- ;
- etc ...
Diverxendo lixeiramente do tema, observo que para a replicación DFS o problema discutido no artigo non é terrible e os ficheiros con nomes longos viaxan con éxito de servidor en servidor (se, por suposto, todo o demais é ).
Tamén me gustaría chamar a súa atención sobre unha utilidade moi útil que me axudou máis dunha vez . Tampouco ten medo aos camiños longos, e pode facer moito. Polo tanto, se a tarefa se reduce a copiar/transferir datos de ficheiros, podes parar aí. Se necesitas facer trucos coas listas de control de acceso ao sistema de ficheiros (DACL), mira para outro lado . A pesar da súa avanzada idade, funcionou de forma excelente en Windows 2012 R2. considéranse métodos de aplicación.
Estaba interesado en ensinar a traballar con camiños longos de PowerShell. Con el é case como nunha broma barbuda sobre Ivan Tsarevich e Vasilisa a Fermosa.
Camiño rápido
Cambie a Linux e non se preocupe por Windows 10/2016/2019 e active a configuración adecuada da política de grupo/axuste o rexistro. Non vou determe neste método en detalle, porque... Xa hai moitos artigos sobre este tema en Internet, por exemplo, .
Tendo en conta que a maioría das empresas ten moitas, por dicilo suavemente, non as últimas versións dos sistemas operativos, este método é rápido só para escribir en papel, a menos que, por suposto, sexas un deses afortunados que teñan poucos sistemas legados e Windows 10. /2016/2019 reina suprema .
O longo camiño
De inmediato, fagamos unha reserva aquí de que os cambios non afectarán o comportamento do Explorador de Windows, pero permitirán utilizar camiños longos nos cmdlets de PowerShell, como Get-Item, Get-ChildItem, Remove-Item, etc.
Primeiro, actualicemos PowerShell. Faise unha, dúas, tres veces.
- Actualizamos o .NET Framework á versión non inferior á 4.5. O sistema operativo debe ser polo menos Windows 7 SP1/2008 R2. Podes descargar a versión actual , ler máis información .
- e instalar Windows Management Framework 5.1
- Reiniciamos a máquina.
As persoas traballadoras poden facer os pasos descritos anteriormente manualmente, os preguiceiros poden facelo coa axuda de SCCM, políticas, scripts e outras ferramentas de automatización.
A versión actual de PowerShell pódese atopar na variable $PSVersionTable. Despois da actualización debería verse algo así:
Agora cando se usan cmdlets Get-ChildItem e similares en lugar do habitual Camiño empregaremos Camiño literal.
O formato do camiño será lixeiramente diferente:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Para a comodidade de converter camiños do formato habitual ao formato Camiño literal podes usar esta función:
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"}
}
Teña en conta que ao configurar o parámetro Camiño literal Non podes usar comodíns (*, ? e así por diante).
Ademais do parámetro Camiño literal, na versión actualizada do cmdlet de PowerShell Get-ChildItem obtivo o parámetro Profundidade, co que podes establecer a profundidade de anidación para a busca recursiva, useino un par de veces e quedei satisfeito.
Agora non tes que preocuparte de que o teu script PS se desvíe polo longo camiño espiñento e non poderás ver ficheiros distantes. Por exemplo, este enfoque axudoume moito ao escribir un script para restablecer o atributo "temporal" dos ficheiros dos cartafoles DFSR. Pero esa é outra historia, que tentarei contar noutro artigo. Espero os teus comentarios interesantes e propoño que fagas a enquisa.
Ligazóns útiles:
Só os usuarios rexistrados poden participar na enquisa. , por favor.
É relevante para vostede o problema dos camiños longos?
-
Si
-
Era relevante, pero xa decidido
-
Interfire, pero non moito
-
Non pensei niso, todo parece funcionar
-
Non
-
Outro (especifique nos comentarios)
Votaron 155 usuarios. 25 usuarios abstivéronse.
Fonte: www.habr.com