¿Por qué existe el límite de longitud de ruta de 260 caracteres en Windows?

Me he encontrado con este problema varias veces en momentos inoportunos:

• Intentando trabajar en proyectos Java de código abierto con rutas profundas
• Almacenar árboles wiki de Fitnesse profundos en el control de fuente
• Un error al intentar usar Bazaar para importar mi árbol de control de código fuente

¿Por qué existe este límite?

¿Por qué no se ha eliminado todavía?

¿Cómo afrontas el límite del camino? Y no, cambiar a Linux o Mac OS X no es una respuesta válida a esta pregunta;)

Citando este artículo https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Limitación máxima de la longitud del camino

En la API de Windows (con algunas excepciones discutidas en los siguientes párrafos), la longitud máxima para una ruta es MAX_PATH , que se define como 260 caracteres. Una ruta local se estructura en el siguiente orden: letra de unidad, dos puntos, barra diagonal inversa, componentes de nombre separados por barras diagonales inversas y un carácter nulo de terminación. Por ejemplo, la ruta máxima en la unidad D es "D: \ alguna cadena de ruta de 256 caracteres <NUL>" donde "<NUL>" representa el carácter nulo de terminación invisible para la página de códigos del sistema actual. (Los caracteres <> se usan aquí para mayor claridad visual y no pueden ser parte de una cadena de ruta válida).

Ahora vemos que es 1 + 2 + 256 + 1 o [unidad] [: \] [ruta] [nulo] = 260. Se podría suponer que 256 es una longitud de cadena fija razonable de los días de DOS. Y volviendo a las API de DOS, nos damos cuenta de que el sistema rastreó la ruta actual por unidad, y tenemos 26 (32 con símbolos) unidades máximas (y directorios actuales).

El INT 0x21 AH = 0x47 dice "Esta función devuelve la descripción de la ruta sin la letra de unidad y la barra invertida inicial". Entonces, vemos que el sistema almacena el CWD como un par (unidad, ruta) y usted solicita la ruta especificando la unidad (1 = A, 2 = B, ...), si especifica un 0, entonces asume la ruta para la unidad devuelta por INT 0x21 AH = 0x15 AL = 0x19. Entonces, ahora sabemos por qué es 260 y no 256, porque esos 4 bytes no están almacenados en la cadena de ruta.

Por qué una cadena de ruta de 256 bytes, porque 640K es suficiente RAM.

Esto no es estrictamente cierto ya que el sistema de archivos NTFS admite rutas de hasta 32k caracteres. Puede usar la api win32 y el \\?\prefijo " " de la ruta para usar más de 260 caracteres.

Una explicación detallada del largo camino del blog del equipo .Net BCL .
Un pequeño extracto resalta el problema con caminos largos

Otra preocupación es el comportamiento inconsistente que resultaría al exponer el soporte de ruta larga. Las rutas largas con el \\?\prefijo se pueden usar en la mayoría de las API de Windows relacionadas con archivos, pero no en todas las API de Windows. Por ejemplo, LoadLibrary, que asigna un módulo a la dirección del proceso de llamada, falla si el nombre del archivo es más largo que MAX_PATH. Esto significa que MoveFile le permitirá mover una DLL a una ubicación tal que su ruta tenga más de 260 caracteres, pero cuando intente cargar la DLL, fallará. Hay ejemplos similares en todas las API de Windows; existen algunas soluciones, pero son caso por caso.

La pregunta es por qué todavía existe la limitación. Sin duda, Windows moderno puede aumentar el lado de MAX_PATHpermitir caminos más largos. ¿Por qué no se ha eliminado la limitación?

• La razón por la que no se puede eliminar es que Windows prometió que nunca cambiaría.

A través del contrato de API, Windows ha garantizado a todas las aplicaciones que las API de archivos estándar nunca devolverán una ruta más larga que los 260caracteres.

Considere el siguiente código correcto :

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

Windows garantizó a mi programa que llenaría mi WIN32_FIND_DATAestructura:

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

Mi aplicación no declaró el valor de la constante MAX_PATH, lo hizo la API de Windows. Mi aplicación usó ese valor definido.

Mi estructura está definida correctamente y solo asigna 592bytes en total. Eso significa que solo puedo recibir un nombre de archivo con menos de 260caracteres. Windows me prometió que si escribía mi aplicación correctamente, mi aplicación continuaría funcionando en el futuro.

Si Windows permitiera nombres de archivo más largos que 260caracteres, entonces mi aplicación existente (que usaba la API correcta correctamente) fallaría.

Para cualquiera que llame a Microsoft para cambiar la MAX_PATHconstante, primero deben asegurarse de que ninguna aplicación existente falle. Por ejemplo, todavía poseo y uso una aplicación de Windows que se escribió para ejecutarse en Windows 3.11. Todavía se ejecuta en Windows 10 de 64 bits. Eso es lo que le brinda la compatibilidad con versiones anteriores.

Microsoft hizo crear una manera de utilizar los 32.768 nombres completos de rutas; pero tuvieron que crear un nuevo contrato de API para hacerlo. Por un lado, debe usar la API de Shell para enumerar archivos (ya que no todos los archivos existen en un disco duro o recurso compartido de red).

Pero también tienen que no romper las aplicaciones de usuario existentes. La gran mayoría de las aplicaciones no utilizan la API de shell para el trabajo de archivos. Todos simplemente llaman FindFirstFile/ FindNextFiley lo llaman un día.

Desde Windows 10. puede eliminar la limitación modificando una clave de registro.

Consejo A partir de Windows 10, versión 1607, las limitaciones de MAX_PATH se han eliminado de las funciones comunes de archivos y directorios de Win32. Sin embargo, debe optar por el nuevo comportamiento.

Una clave de registro le permite habilitar o deshabilitar el nuevo comportamiento de ruta larga. Para habilitar el comportamiento de ruta larga, establezca la clave de registro en HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Tipo:) REG_DWORD. El sistema almacenará en caché el valor de la clave (por proceso) después de la primera llamada a un archivo Win32 o función de directorio afectados (la lista sigue). La clave de registro no se volverá a cargar durante la vida útil del proceso. Para que todas las aplicaciones en el sistema reconozcan el valor de la clave, es posible que sea necesario reiniciar porque algunos procesos pueden haberse iniciado antes de configurar la clave. La clave de registro también se puede controlar mediante la Política de grupo en Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. También puede habilitar el nuevo comportamiento de ruta larga por aplicación a través del manifiesto:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Puede montar una carpeta como unidad. Desde la línea de comando, si tiene una ruta C:\path\to\long\folder, puede asignarla a la letra de unidad X:usando:

subst x: \path\to\long\folder

Una forma de hacer frente al límite de ruta es acortar las entradas de ruta con enlaces simbólicos.

Por ejemplo:

1. crear un C:\pdirectorio para mantener enlaces cortos a rutas largas
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. agregar C:\p\fooa su ruta en lugar de la ruta larga

Puede habilitar nombres de ruta largos con PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

Otra versión es usar una Política de grupo en Computer Configuration/ Administrative Templates/ System/ Filesystem:

En cuanto a por qué esto todavía existe: MS no lo considera una prioridad y valora la compatibilidad con versiones anteriores sobre el avance de su sistema operativo (al menos en este caso).

Una solución alternativa que uso es usar los "nombres cortos" para los directorios en la ruta, en lugar de sus versiones estándar legibles por humanos. Así , por ejemplo, para C:\Program Files\que yo usaría C:\PROGRA~1\ Usted puede encontrar los equivalentes de nombre corto utilizando dir /x.

En cuanto a cómo hacer frente a la limitación de tamaño de ruta en Windows: usar 7zip para empacar (y desempaquetar) sus archivos confidenciales de longitud de ruta parece una solución viable. Lo he usado para transportar varias instalaciones IDE (esas rutas de complementos de Eclipse, ¡ay!) Y montones de documentación autogenerada y hasta ahora no he tenido un solo problema.

No estoy seguro de cómo evade el límite de 260 caracteres establecido por Windows (desde un punto de vista técnico), pero bueno, ¡funciona!

Más detalles en su página de SourceForge aquí :

"NTFS puede admitir nombres de ruta de hasta 32,000 caracteres de longitud".

7-zip también admite nombres tan largos.

Pero está deshabilitado en el código SFX. A algunos usuarios no les gustan los caminos largos, ya que no entienden cómo trabajar con ellos. Es por eso que lo he deshabilitado en el código SFX.

y notas de lanzamiento :

9.32 alfa 01/12/2013

• Soporte mejorado para nombres de ruta de archivo de más de 260 caracteres.

4.44 beta 2007-01-20

• 7-Zip ahora admite nombres de ruta de archivo de más de 260 caracteres.

NOTA IMPORTANTE: Para que esto funcione correctamente, deberá especificar la ruta de destino en el cuadro de diálogo "Extraer" de 7zip directamente, en lugar de arrastrar y soltar los archivos en la carpeta deseada. De lo contrario, la carpeta "Temp" se usará como caché provisional y rebotará en la misma limitación de 260 caracteres una vez que el Explorador de Windows comience a mover los archivos a su "lugar de descanso final". Consulte las respuestas a esta pregunta para obtener más información.

Lo hace, y es un valor predeterminado por alguna razón, pero podría anularlo fácilmente con esta clave de registro:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

Ver: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Otra forma de lidiar con esto es usar Cygwin, dependiendo de lo que desee hacer con los archivos (es decir, si los comandos de Cygwin se adaptan a sus necesidades)

Por ejemplo, permite copiar, mover o renombrar archivos que incluso el Explorador de Windows no puede. O, por supuesto, lidiar con su contenido como md5sum, grep, gzip, etc.

También para los programas que está codificando, podría vincularlos a la DLL de Cygwin y les permitiría usar rutas largas (aunque no he probado esto)