Existe la creencia de que Windows no soporta paths de más de 256 caracteres. Esta limitación está heredada de versiones anteriores en las que los sistemas de ficheros no permitían direccionar rutas más largas. Recordemos también que MS-DOS imponía la limitación del nombre de fichero a 8 caracteres más 3 de extensión. Por cierto, de ahí viene también la creencia de que Windows no soporta extensiones de más de 3 caracteres.
Por convenio los path en Windows no pueden superar los 260 caracteres (sí, 260, no 256). Esto puede encontrarse en la documentación de las APIs. Sin embargo, esta limitación está impuesta por la API de Win32 y no por el sistema de ficheros NTFS, que sí soporta paths de mayor longitud.
La mayoría de las aplicaciones Windows respetan el convenio de nomenclatura, lo que significa que un PATH no puede exceder los 260 caracteres y cada componente del Path tampoco puede superar los 260 caracteres. Ahora bien, hemos dicho que la limitación es un convenio que impone la API Win32. Esto no significa que no se puedan crear paths de mayor longitud, simplemente que está desaconsejado.
Algunas APIs Win32 incorporan un sistema para eliminar esta restricción. Es el caso de CreateDirectory. Con el siguiente ejemplo vamos a crear la ruta C:\<200Caracteres>\<200 Caracteres>\<200 Caracteres>.<3 caracteres>. Eso es un Path de 608 caracteres (excluyendo el marcador NULL). He parado en 608 porque me estaba haciendo un lio al copiar y pegar, pero podríamos llegar a 32767 caracteres sin despeinarnos :)
int _tmain(int argc, _TCHAR* argv[])
{
CreateDirectory(TEXT("\\\\?\\C:\\TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest"),NULL);
CreateDirectory(TEXT("\\\\?\\C:\\TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest\\TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest"),NULL);
CreateFile(TEXT("\\\\?\\C:\\TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest\\TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest\\TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest.txt"),GENERIC_WRITE,0,NULL,CREATE_NEW,FILE_ATTRIBUTE_NORMAL,NULL);
return 0;
}
El vudú se consigue anteponiendo \\?\ al path. De esta forma le decimos a la API de Win32 que no nos imponga el límite de los 260 caracteres. Los inconvenientes que tiene esto es que todas las herramientas que se acojan al convenio de los 260 caracteres podrían no funcionar o comportarse de forma extraña con estos paths.
Un ejemplo es la inconsistencia dentro de la propia Shell de Windows. Cuando se encuentre con nuestra ruta, la visualizará adecuadamente y podremos editar nuestro fichero de texto con, digamos, Notepad, que también soporta estas rutas. Sin embargo, si copiamos la ruta que nos da Explorer, veremos que es algo así: C:\TESTTE~1\TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest
Es decir, 213 caracteres. El primer directorio lo acorta usando el formato MS-DOS (siempre que esté activado en Windows). Esto evita problemas a programas que no soporten paths largos.
Si intentásemos listar nuestro fichero en PowerShell, nos encontraríamos con un problemilla, ya que no soporta rutas largas y nos daría este error:
¿Por qué PowerShell no puede ver rutas largas? Porque está en .NET y sin hacer magia negra (que sí, se puede) las aplicaciones .NET no soportan paths fuera de la convención de 260 caracteres. El motivo es simple… Win32 no está pensado para paths fuera de convención y .NET se apoya en Win32.
Anteponiendo \\?\ a un path, no sólo estamos diciéndole a Win32 que elimine la restricción de 260 caracteres, sino que estamos haciendo que se envíe casi sin control al sistema de ficheros. ¿Os imagináis crear un directorio llamado C:\CON\CON? Es un nombre ilegal en Windows y la Shell nunca os permitirá crearlo pero… ¿podemos?
int _tmain(int argc, _TCHAR* argv[])
{
CreateDirectory(TEXT("\\\\?\\C:\\CON"),NULL);
CreateDirectory(TEXT("\\\\?\\C:\\CON\\CON"),NULL);
return 0;
}
Esto nos crea un bollo importante, porque la Shell no nos va a dejar acceder:
CMD no va a dejarnos tampoco:
PowerShell ni probamos porque es .NET. ¿Qué podemos hacer? Sorprendentemente RMDIR si soporta estas rutas, así que nos lo podemos cargar con “rmdir /s /q \\.\C:\CON”
Conclusión
El sistema de ficheros de Windows sí soporta paths de más de 260 caracteres y sí pueden usarse. Sin embargo, muchas herramientas y algunas APIs de Windows no se comportan adecuadamente con rutas largas, por lo que se recomienda evitarlas.
En general sólo suelen utilizarse rutas de más de 260 caracteres cuando estamos interoperando con otros SSOO donde estas rutas son comunes. Las herramientas destinadas para estos entornos, como podría ser una copia de un servidor remoto con RoboCopy, se comportan adecuadamente.
Poder, se puede… pero asegúrate de que las herramientas que uses estén preparadas ;)
Efectivamente, si de alguna forma se crean mas allá del limite, problemas al eliminar. Para poder eliminar carpetas mas allá del límite hay varias formas, una bastante curiosa, con robocopy: http://www.sysadmit.com/2015/08/windows-borrar-rutas-largas.html
Esto demuestra que windows es arcaico y que es una bazofia en cuanto quieres utilizarlo de forma profesional, no hay que irse muy lejos he tenido problemas por utilizar eclipse dentro de una carpeta dentro del home del usuario con plugins instalados, no me dejaba copiar archivos que pertenecientes al plugin de flex si este eclipse estaba en una carpeta en el escritorio de windows, se piensan que 256 caracteres es mas que de sobra, pero no lo es se supone que un disco duro y la creacion de directorios (carpetas) es para clasificar si tienes una estructura de carpetas bastante amplia dividida por imaginemos decadas dentro de las decadas años, dentro de los años meses y dentro de los meses categorias de documentos y dentro subcategorias llegas facilmente a superar esos 260 caracteres, ademas ese limite de 260 caracteres es falso, para que el sistema funcione correctamente y poder utilizar todas las fucniones de windows tienes que restar una serie de caracteres que incluye el versionado de windows a las rutas, he tenido que hacer maravillas para recuperar un fichero que al ser borrado estaba dentro del versionado pero este era inaccesible porque superaba los 260 caracteres cuando el original eran justo 259 caraceres, no importa la potencia grafica de un sistema operativo y cada sistema operativo sirve para una determinada serie de historias, pero algo tan basico como eso anclarse en el pasado acaba pasando factura, ya lo veremos con el paso del tiempo,deberian centrarse en quitar esas antiguas limitaciones ademas con esto demuestran que siguen haciendo chapuzas, ya lo hicieron con windows 95 y windows 98 tanto vender que eran sistemas operativos de 32 bits y era realmente falso, eran sistemas de 16 el primer sistema operativo de 32 bits reales fue el windows xp y OS/2 por ejemplo ya utilizaba los 32 bits desde al menos la version 2.1 si no me equivoco, seguro seguro la version 3 que es cuando salio windows 95, es decir desde que existia los 386 hemos desperdiciado potencia de equipo incluso con los pentium (instale el os2/warp v3 y me iba de maravilla incluso con aplicaciones nativas de windows 3.11 y disponia de posibilidad de personalizar muchas sesiones de ms-dos personalizadas mejores que el propio msdos saltandose la limitacion de los 640 kilobytes eso si que era un buen sistema operativo pero claro el marketing lo es todo, es como la programacion actual basada en frameworks y en sus limitaciones, he visto cagadas muy gordas de perder mucho dinero por tener que cambiar de framework por encontrarse con una limitacion o bug insalvable insalvable porque habria que tocar el core para solventarlo estamos en la epoca de la programacion chapuza, utilizo frameworks y programo sobro otro lenguaje que me da esto echo pero si me encuentro con un bug en el framework como es intocable porque tenemos aplicaciones web que dependen del mismo framework adios desarrollo y consiguiente perdida de pasta y todo porque ellos (las empresas) no valoran la calidad sino la velocidad de desarrollo de aplicaciones mierdas e inacabadas para obtener dinero cuanto antes, no quieren a un tio que desarrolle en condiciones quieres un tio que desarrollen mierdas rapidas y luego vender soporte si quieres corregirlo tienes que contratar soporte de forma anual, los usuarios pagan por un producto que desde que sale de fabrica tiene que funcionar, imaginaros que me venden un coche que funciona con un combustible con el cual solo es capaz de andar a 50 kilometros por hora lo sacan a la venta y te das cuenta que no va mas, y para quejarte tienes que pagar un soporte para que venga un tecnico te cambie una pieza para que tu coche pueda funcionar con otro combustible y poder coger los 120 kilometros por hora que es por lo que ya habias pagado, eso es lo que consiguen con esta programacion mierda, no se entrega algo terminado, y encima se nos menosprecia, no se duda de lo que cobra un arquitecto y eso que su trabajo requiere de menos calculos que los nuestros su trabajo es mas casi de sota caballo y rey es decir el techo tiene que aguantar nose cuantos mil kilos de peso con nieve y tal, y te dicen los materiales a utilizar y tal
en la informatica es mucho mas complicado por el mero echo de que ningun sistema es igual a otro, incluso dos instalaciones identicas pueden no funcionar cosa que no ocurre en la construccion si un suelo es identico a otro dos construcciones identicas construidas de identica forma tendran exactamente los mismos calculos y aguantaran casi exactamente el mismo tiempo, en la informatica dos sitemas informaticos identicos con el mismo software identico y dos programaciones identicas pueden no funcionar correctamente
otro ejemplo mas cercano que yo he sufrido con los frameworks o en su caso con un lenguaje de programcion concreto es con java dos aplicaciones que supuestamente deberian funcionar en cualquier sistema operativo de forma identica, no lo hacen no se comportan igual y no se dibujan igual, antes de que existieran los botones con imagenes se simulaba con un panel y un objeto imagen pues bien si lo programaba en windows, a pesar de cambiar las rutas la forma de añadir las imagenes en los botones tenia que cambiar porque a pesar de cambiar las rutas de las imagenes estas no se dibujaban en linux en los paneles mientras que en windows si, y si lo programaba bajo eclipse en linux pasaba lo mismo a la inversa no funcionaba igual, con lo que ya no es tan portable como prometen, lo mismo ocurre con los frameworks, si yo utilizo un framework y luego no funciona bajo un navegador y el cliente requiere que funcione en el el framework ya no te sirve porque complicamos ya de por si el desarrollo mañana te sacan otra version y el cliente quiere ese nuevo efecto en su web y ya la has liado complicas mucho mas la programación, ademas que 650 kilobytes es bastante por mucho que tengamos adsl de la leche aun no se deberian utilizar 1 mega para una pagina en una tiempo en el que los smartphone aun tienen limitaciones de megas y que dudo que en un tiempo cercano exista una tarifa plana real sin limite de megas como ocurre en las adsl.
bueno ya me he enrrollado demasiado queria exponer muchas cosas y al final las he mezclado.
Salu2.