Copia de archivos de Linux a Windows con nombres largos

Windows tiene que leer unos archivos en una partición NTFS copiados desde una partición ext4 usada por un Linux, pero hay archivos con nombres demasiado largos y Windows se pierde. ¿Hay alguna manera de forzar la copia desde Linux a la partición NTFS para que los archivos sean más compatibles con lo que espera Windows?

Windows no tiene problema si esos mismos ficheros con la misma longitud de nombre son creados por él, automáticamente asigna unos segundos nombres 8.3, empiezan a aparecer las carpetas acabadas en ~1 y demás, pero si el fichero es creado desde Linux eso no sucede.

Tal vez si comprimo todo en Linux en un archivo y lo descomprimo en Windows el inconveniente desaparece, no lo he probado pero es una solución que no conviene. Tampoco pueden ser los programas de Windows que acceden a ext4.
Podrías poner algún ejemplo de alguno de esos nombres?
Con ruta y todo quedan algo así:

C:\1213 copia\Departamento Informatica Documentos Profesional Ocupacional - revision abril\Microsoft Training and Certification\MS 10266A Programming in C# with Visual Studio 2010\MS 10266A - Programming in C# with Visual Studio 2010 - Programa.pdf

Una burrada de largo pero es como están, no debo cambiarlo. No hay símbolos extraños para NTFS o ext4 y no creo que el problema sean algunos caracteres delicados como los espacios, diría que simplemente es la longitud. De hecho Windows sólo se queja de eso, dice que son demasiado largos para trabajar con ellos y únicamente me deja abrirlos, nada de operaciones con ficheros (copiar, borrar o lo que sea) o hasta ver las propiedades del archivo. Si la copia inicial se hace desde Windows en vez de Linux, si el archivo en NTFS lo escribe Windows en vez de hacerlo Linux, no hay ningún problema, la ruta es igual de larga pero el archivo funciona con normalidad.
bas escribió:Con ruta y todo quedan algo así:

C:\1213 copia\Departamento Informatica Documentos Profesional Ocupacional - revision abril\Microsoft Training and Certification\MS 10266A Programming in C# with Visual Studio 2010\MS 10266A - Programming in C# with Visual Studio 2010 - Programa.pdf

Una burrada de largo pero es como están, no debo cambiarlo. No hay símbolos extraños para NTFS o ext4 y no creo que el problema sean algunos caracteres delicados como los espacios, diría que simplemente es la longitud. De hecho Windows sólo se queja de eso, dice que son demasiado largos para operar con ellos y únicamente me deja abrirlos, nada de operaciones con ficheros (copiar, borrar o lo que sea) o hasta ver las propiedades del archivo. Si la copia inicial se hace desde Windows en vez de Linux, si el archivo lo escribe Windows en NTFS en vez de hacerlo Linux, no hay ningún problema, la ruta es igual de larga pero el archivo funciona con normalidad.


Si eso que dices es así, siempre puedes coger y cambiar el nombre de las rutas de más hacia fuera:

"C:\1213 copia\D\M\MS 10266A Programming in C# with Visual Studio 2010\MS 10266A - Programming in C# with Visual Studio 2010 - Programa.pdf"

y luego volver a ponerle el nombre que tenía (todo esto desde windows). Al acortar el tamaño del nombre, te dejará trabajar con ellos. Al volver a cambiar el nombre, ya se habrá hecho desde windows, y hará las modificaciones oportunas que tu has comentado para poder trabajar con los archivos.

Lo de cambiar los nombres de más hacia fuera es porque así se modifican y se vuelven a hacer "funcionales" muchos más archivos de golpe.
La cosa es que desde Windows no debería hacerse nada, idealmente tendría que ser un proceso realizado solo desde Linux. Alternativas hay, en el primer mensaje también digo alguna, pero necesitan estar en Windows y no valen. A lo guarro podría hacerse un script para estas cosas de manera que arranquen al entrar en Windows y se haga la copia bien, pero es una cutrada, no mola, Windows no debería pintar nada.

Nunca trabajo con nombres tan largos, siempre lo evito, y ahora me encuentro con esto que no sé muy bien cómo abordarlo. ¿Es algún tipo de limitación en el soporte NTFS de Linux?
bas escribió:La cosa es que desde Windows no debería hacerse nada, idealmente tendría que ser un proceso realizado solo desde Linux. Alternativas hay, en el primer mensaje también digo alguna, pero necesitan estar en Windows y no valen. A lo guarro podría hacerse un script para estas cosas de manera que arranquen al entrar en Windows y se haga la copia bien, pero es una cutrada, no mola, Windows no debería pintar nada.

Nunca trabajo con nombres tan largos, siempre lo evito, y ahora me encuentro con esto que no sé muy bien cómo abordarlo. ¿Es algún tipo de limitación en el soporte NTFS de Linux?


Nada de limitaciones de Linux en NTFS ni nada por el estilo (o al menos yo no estoy enterado de esto).

Windows está limitado a trabajar con nombres de 255 caracteres de longitud (nombre de archivo + carpetas donde se encuentran). Supongo que internamente, y para solucionar este problema, windows se creará en algún sitio las "equivalencias" para cada una de estas carpetas ("Archiv~1" en lugar de "Archivos de programa") y así cuando le haga falta, trabajará con los nombres cortos en lugar de con los largos. Como digo, eso será algo que hace windows internamente. Si el movimiento de archivos lo haces desde Linux, supongo que Windows no se crea nada, con lo que estos nombres cortos para windows no existen y no puede trabajar con ellos...

Todo esto son suposiciones, ya que practicamente nunca he tenido problema con nombres largos, y cuando los he tenido, la solución ha sido cambiar el nombre de la ruta del archivo por uno más corto desde el propio windows.
Copiado de un foro de programacion

Problema con los nombres largos

Resulta bastante chocante que la API de windows limite la máxima longitud para una ruta al valor de MAX_PATH, definido como 260 caracteres. Se trata únicamente de una limitación en la API, ya que el kernel de windows está preparado para manejar rutas muchísimo más largas. Como consecuencia, muchas aplicaciones fallan con rutas largas, desde los comandos de terminal hasta las utilidades gráficas del sistema.

Para evitar en parte este problema, podemos usar en nuestras aplicaciones las versiones unicode de las funciones ANSI de la API. Estas versiones unicode admiten como parámetros rutas de hasta 32.767 caracteres, suficientemente largas para un uso normal.


Así que el problema es de Windows y sus programas dependiendo de la API usado en ellos.
Darumo escribió:Copiado de un foro de programacion

Problema con los nombres largos

Resulta bastante chocante que la API de windows limite la máxima longitud para una ruta al valor de MAX_PATH, definido como 260 caracteres. Se trata únicamente de una limitación en la API, ya que el kernel de windows está preparado para manejar rutas muchísimo más largas. Como consecuencia, muchas aplicaciones fallan con rutas largas, desde los comandos de terminal hasta las utilidades gráficas del sistema.

Para evitar en parte este problema, podemos usar en nuestras aplicaciones las versiones unicode de las funciones ANSI de la API. Estas versiones unicode admiten como parámetros rutas de hasta 32.767 caracteres, suficientemente largas para un uso normal.


Así que el problema es de Windows y sus programas dependiendo de la API usado en ellos.


Vale, ya me has sacado de dudas a mi también XD
De hecho las limitaciones de longitud en NTFS y ext4 creo que son las mismas, unos 255 caracteres por cada elemento de la ruta. Linux lo mantiene así, puedes anidar sin problemas directorios de 255 caracteres, pero Windows decide que 255 sea el tamaño máximo de toda la ruta incluyendo el nombre del archivo.

De todas maneras algo no me cuadra, creando archivos a mano la shell de Windows no te permite pasar de los 255, pero si lo creado lo ha realizado otro programa preparado para esquivar esa limitación, un posible compresor descomprimiendo un zip con nombres largos, por ejemplo, la shell no tiene problemas para trabajar con esos ficheros creados. No puede crearlos pero sí operar con normalidad una vez creados, salvo si han sido creados desde Linux, hay algo por ahí que se pierde.

Lo de ~1 en principio Windows no lo necesita, creo que simplemente existe por un tema de compatibilidad con sistemas antiguos, se podría desactivar. No sé, sí, tal vez solo sea eso, quizá quitando los nombres cortos desaparece el problema, puede que estando activado sí sea algo que requiera y se convierta en el motivo de estos errores, ni idea. Aún así me extrañaría que no hubiera nada para solucionarlo tal cual desde Linux.
bas escribió:De hecho las limitaciones de longitud en NTFS y ext4 creo que son las mismas, unos 255 caracteres por cada elemento de la ruta. Linux lo mantiene así, puedes anidar sin problemas directorios de 255 caracteres, pero Windows decide que 255 sea el tamaño máximo de toda la ruta incluyendo el nombre del archivo.

De todas maneras algo no me cuadra, creando archivos a mano la shell de Windows no te permite pasar de los 255, pero si lo creado lo ha realizado otro programa preparado para esquivar esa limitación, un posible compresor descomprimiendo un zip con nombres largos, por ejemplo, la shell no tiene problemas para trabajar con esos ficheros creados. No puede crearlos pero sí operar con normalidad una vez creados, salvo si han sido creados desde Linux, hay algo por ahí que se pierde.

Lo de ~1 en principio Windows no lo necesita, creo que simplemente existe por un tema de compatibilidad con sistemas antiguos, se podría desactivar. No sé, sí, tal vez solo sea eso, quizá quitando los nombres cortos desaparece el problema, puede que estando activado sí sea algo que requiera y se convierta en el motivo de estos errores, ni idea. Aún así me extrañaría que no hubiera nada para solucionarlo tal cual desde Linux.


Es que en caso de que eso fuese así, lo mismo windows internamente modifica alguna cosa del propio SO (como ya he dicho) mientras se hace este movimiento para saber para tirar en caso de que estos archivos tengan nombres más grandes de la cuenta. Y en cambio si se hace desde linux (o desde cualquier otro SO) todas estas modificaciones internas en Windows no se hacen ya que es otro SO diferente el que está gestionando el movimiento.

En cambio, si un compresor descomprime esos archivos como tu has dicho, el movimiento se gestiona desde el propio Windows, con lo que todo lo que tenga que hacer para que los nombres funcionen lo va haciendo sobre la marcha.

Como ya he dicho antes también, no se si esto es así o no, pero lo que quiero decir es que no me parece tan raro en absoluto que ocurra el problema que comentas.
Sí, pero volvemos al primer post, Windows crea sus nombres cortos, Linux pasa de los nombres cortos que necesita Windows y yo querría poder rodear el inconveniente usando solo Linux.

No sé muy bien dónde guarda Windows esos nombres cortos pero suponía que podría formar parte de las propiedades del propio NTFS (parece ser que así es, o al menos NTFS está preparado para ello, Windows no necesitaría más). Por eso después preguntaba si había algo al respecto entre Linux y NTFS, y mirando kernel.org veo esto:

The driver does not support short file names in general. For backwards
compatibility, we implement access to files using their short file names if
they exist. The driver will not create short file names however, and a
rename will discard any existing short file name.

Since 2.0.8:
- Mostly drop support for short file names (for backwards compatibility
we only support accessing files via their short file name if one
exists).


Mirando en general diferentes implementaciones para NTFS veo que esa es la tónica general, en Linux se pasa por completo de los nombres cortos, se considera desfasado, nunca se crean, se ignora la forma que sigue Windows.

Aún así parece que usando getfattr y setfattr se puede trabajar con los nombres cortos con lo que, por ejemplo, debería buscar o hacer un script que a medida que fuera copiando los archivos también fuese creando un nombre corto y modificando los atributos de cada fichero y directorio para añadírselo.

La verdad es que me parece un tanto ortopédico, más que nada porque me cuesta creer que no haya algo más simple, se trata de que lo vea un SO tan "desconocido" como Windows. Tiene que haber algo, activar alguna opción, algún parámetro, algo sencillo que evite tener que pasar por este setfattr cada vez que uno quiere copiar algo a una partición NTFS que solo leerá Windows.
bas escribió:La verdad es que me parece un tanto ortopédico, más que nada porque me cuesta creer que no haya algo más simple, se trata de que lo vea un SO tan "desconocido" como Windows. Tiene que haber algo, activar alguna opción, algún parámetro, algo sencillo que evite tener que pasar por este setfattr cada vez que uno quiere copiar algo a una partición NTFS que solo leerá Windows.

Hombre, pero no lo pongas como si tu caso particular (que es bastante extraño) fuese la tonica general. La realidad es que el 99,9% de usuarios no va a encontrar nunca este problema tan puntual que has encontrado tu, asi que tiene sentido quitar el soporte para eso del correspondiente modulo.

Luego esta el 0,1% restante, que tendra que buscar otra manera, ya sea simplificar las rutas a algo mas razonable, usar utilidades adicionales, etc.
Bueno, hasta ahora no me he encontrado con esto porque siempre he evitado los nombres largos, es una situación rara simplemente porque no es habitual trabajar con nombres tan largos. Pero si se piensa que Windows tiene la limitación total de 260 caracteres y que requiere de nombres cortos ya me resulta bastante más sorprendente, que estamos hablando del común Windows con su común NTFS, que no nos referimos a un BeOS con su BeFS, por decir algo (ni idea cómo de bien o mal Linux soporta BeFS).

Vaya, que dudo mucho que esto sea algo tan sumamente excepcional como para encontrarme en una situación tan única, no veo demasiado sentido a que no haya soluciones cercanas a no hacer nada y aún más si se tiene en cuenta que el kernel lo soportaba. Con un vistazo rápido en las opciones del actual no he visto la de crear nombres cortos, quizá me lo he saltado, pero lo lógico, porque no costaría nada a pesar de que digan que en general ya no se soporta, sería que hubiera algo para activarlo.
bas escribió:Bueno, hasta ahora no me he encontrado con esto porque siempre he evitado los nombres largos, es una situación rara simplemente porque no es habitual trabajar con nombres tan largos. Pero si se piensa que Windows tiene la limitación total de 260 caracteres y que requiere de nombres cortos ya me resulta bastante más sorprendente, que estamos hablando del común Windows con su común NTFS, que no nos referimos a un BeOS con su BeFS, por decir algo (ni idea cómo de bien o mal Linux soporta BeFS).

Vaya, que dudo mucho que esto sea algo tan sumamente excepcional como para encontrarme en una situación tan única, no veo demasiado sentido a que no haya soluciones cercanas a no hacer nada y aún más si se tiene en cuenta que el kernel lo soportaba. Con un vistazo rápido en las opciones del actual no he visto la de crear nombres cortos, quizá me lo he saltado, pero lo lógico, porque no costaría nada a pesar de que digan que en general ya no se soporta, sería que hubiera algo para activarlo.



Sistemas privativos, soluciones privativas. Posibilidades solo bajo demanda y presupuestos elevados. MAX_PATH es una limitación del sistema operativo la cual no puede/debe ser modificada bajo posibles mayores problemas y no habrá acceso al código ni documentación fácil al respecto. Ni hablar que sera mas fácil adaptar los documentos que cada pc que tuviera que tratar con ellos XD.

Sino están siendo usadas como referencia absoluta de ningún programa yo acortaría nombres, por eso para backups solo creo una carpeta llamada BK y fecha reducida como mucho. Si necesitas transportarlos, organización absoluta y no renombrarlos puedes comprimirlos con nombre corte teniendo el nombre original de nuevo al descomprimirlo (descomprimelo en otro lado).
Si andas con programación deberías estar acostumbrado a estas limitaciones que son autoimpuestas y el porque usar nombres de variables cortos ^^.

Vamos, usar en vez de "Departamento Informatica Documentos Profesional Ocupacional - revision abril\Microsoft Training and Certification" poner algo como"DeptIDPO-Abril/MSTrainingAndCert" te ahorraría muchos caracteres y creo yo que cualquiera entendería las siglas y acortamientos aunque no los usara a menudo.
Supongo por lo que dices que los datos están en el mismo disco físico, en la misma máquina. Lo que comentas de comprimir los ficheros supongo que funcionaría, además, si comprimes en zip, en windows no tendrías ni que descomprimir porque se soporta nativamente. Por otro lado, has probado algún driver o tool para leer directamente extended desde windows?
14 respuestas