Creo que, al igual que a mí, a usted también le ha tocado ver rutas como estas !!! Importante____Nuevo____!!! ¡No eliminar!!! Orden №98819-649-B del 30 de febrero de 1985 sobre el nombramiento de Kozlov Ivan Alexandrovich como interino del departamento encargado de atender a clientes VIP corporativos y de organizar reuniones de negocios en los pasillos.doc.
Y a menudo no se puede abrir un documento así en Windows de inmediato. Algunos practican soluciones alternativas como el mapeo de unidades, otros utilizan administradores de archivos que pueden trabajar con rutas largas: Far Manager, Total Commander y similares. Además, muchos han observado con tristeza cómo su script de PowerShell, que requirió mucho esfuerzo y funcionó a la perfección en un entorno de prueba, en producción se quejaba impotente de la tarea abrumadora: La ruta especificada, el nombre de archivo, o ambos son demasiado largos. El nombre de archivo completo debe tener menos de 260 caracteres, y el nombre del directorio debe tener menos de 248 caracteres.
Como resultó, 260 caracteres no son suficientes para "casi todos". Si tiene interés en superar los límites permitidos, le invito a seguir leyendo.
Aquí hay algunas de las tristes consecuencias de la limitación en la longitud de la ruta de archivo:
- en el servidor hay una carpeta, por ejemplo, D:DataSharedAccounting, que está compartida por SMB y se monta a los usuarios como unidad de red S; los usuarios crean archivos que los administradores/scripts no podrán leer al acceder localmente desde el servidor, ya que la ruta absoluta resulta ser más larga que la de la red;
- ;
- ;
- al migrar datos desde otros sistemas en los que hay menos restricciones en la longitud de la ruta, en el nuevo entorno, parte de ellos quedará inaccesible sin realizar algunos ajustes;
- ;
- etc...
Desviándome un poco del tema, señalaré que para la replicación DFS el problema tratado en este artículo no es aterrador y los archivos con nombres largos viajan con éxito de servidor a servidor (si, por supuesto, todo lo demás lo han hecho correctamente) ).
También me gustaría llamar la atención sobre una utilidad muy útil que en varias ocasiones me ha salvado . Esta herramienta tampoco teme a las rutas largas y es capaz de hacer muchas cosas. Por lo tanto, si la tarea consiste en copiar/mover datos de archivos, se puede detener en ella. Si necesita hacer ajustes con las listas de control de acceso en el sistema de archivos (DACL), mire hacia . A pesar de su edad, demostró un gran rendimiento en Windows 2012 R2. se han considerado formas de aplicación.
Me interesaba aprender a trabajar con rutas largas en PowerShell. Es casi como el viejo chiste de Iván el Terrible y Vasilisa la Bella.
Método rápido
Pasar a Linux y no preocuparse de Windows 10/2016/2019 y habilitar el parámetro correspondiente en la política de grupo/o modificar el registro. No me detendré mucho en este método, ya que hay muchos artículos en línea sobre este tema, por ejemplo, .
Teniendo en cuenta que en la mayoría de las empresas hay muchas, por decirlo de alguna manera, versiones no recientes de sistemas operativos, este método es rápido solo para escribir en papel, a menos que seas de esos afortunados que tienen pocas sistemas heredados y usan Windows 10/2016/2019.
Método largo
Aquí aclaramos de inmediato que los cambios no afectarán el comportamiento del explorador de Windows, sino que permitirán usar rutas largas en los cmdlets de PowerShell, como Get-Item, Get-ChildItem, Remove-Item, etc.
Primero, actualizaremos PowerShell. Se hace en un abrir y cerrar de ojos.
- Actualizamos .NET Framework a una versión no inferior a 4.5. El sistema operativo debe ser al menos Windows 7 SP1/2008 R2. La versión actual se puede descargar , leer información adicional .
- e instalar el Windows Management Framework 5.1
- Reiniciamos la máquina.
Los trabajadores diligentes pueden realizar los pasos anteriores manualmente, los perezosos — mediante SCCM, políticas, scripts y otros medios de automatización.
La versión actual de PowerShell se puede conocer a través de la variable $PSVersionTable. Después de la actualización debería verse algo así:
Ahora, al usar los cmdlets Get-ChildItem y similares, en lugar del habitual Path usaremos LiteralPath.
El formato de las rutas será un poco diferente:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Para facilitar la conversión de rutas del formato habitual al formato LiteralPath se puede usar la siguiente 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"}
}
Tenga en cuenta que al establecer el parámetro LiteralPath no se pueden usar caracteres comodín (*, ? etc.).
Además del parámetro LiteralPath, en la versión actualizada de PowerShell, el cmdlet Get-ChildItem recibió el parámetro Depth, que permite establecer la profundidad de anidamiento para búsquedas recursivas. Lo he usado un par de veces y estoy satisfecho.
Ahora puedes estar tranquilo, sabiendo que tu script de PS no se desviará de su largo y tortuoso camino ni ignorará archivos lejanos. Personalmente, este enfoque me ayudó mucho al escribir un script para eliminar el atributo 'temporal' de los archivos en carpetas DFSR. Pero esa es otra historia, de la cual intentaré hablar en otro artículo. Espero sus comentarios interesantes y les propongo participar en la encuesta.
Enlaces útiles:
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Es un problema de rutas largas relevante para ti?
Sí
Era relevante, pero ya lo resolví
Es molesto, pero no demasiado
No he pensado en ello, parece que todo funciona
No
Otro (especificar en los comentarios)
155 usuarios votaron. 25 usuarios se abstuvieron.
Fuente: habr.com
