› Foros › PC › Software libre
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.
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?
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.
Darumo escribió:Copiado de un foro de programacionProblema 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.
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.
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).
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.
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.