winapi - que - youtube google
¿Debo lidiar con archivos de más de MAX_PATH? (8)
Acabo de tener un caso interesante.
Mi software informó una falla causada por una ruta que es más larga que MAX_PATH.
La ruta era simplemente un documento antiguo en Mis documentos, por ejemplo:
C:/Documents and Settings/Bill/Some Stupid FOlder Name/A really ridiculously long file thats really very very very..........very long.pdf
Longitud total 269 caracteres (MAX_PATH == 260).
El usuario no estaba usando un disco duro externo ni nada de eso. Este era un archivo en una unidad administrada de Windows.
Así que mi pregunta es esta. ¿Debería importarme?
No estoy diciendo que pueda lidiar con los caminos largos, me pregunto si debería . Sí, soy consciente del "/? /" Corte unicode en algunas API de Win32, pero parece que este truco no está exento de riesgos (como está cambiando el comportamiento de la forma en que las API analizan las rutas) y tampoco es compatible con todas las API.
Entonces, de todos modos, permítanme decir mi posición / afirmaciones:
- Primero, presumiblemente, la única forma en que el usuario pudo romper este límite es si la aplicación que usó usa el truco Unicode especial. Es un archivo PDF, así que tal vez la herramienta PDF que usó usa este truco.
- Traté de reproducir esto (usando el hack Unicode) y experimenté. Lo que encontré fue que aunque el archivo aparece en Explorer, no puedo hacer nada con él. No puedo abrirlo, no puedo elegir "Propiedades" (Windows 7). Otras aplicaciones comunes no pueden abrir el archivo (por ejemplo, IE, Firefox, Bloc de notas). Explorer tampoco me permitirá crear archivos / directorios demasiado largos, solo se niega. Lo mismo para la herramienta de línea de comandos cmd.exe.
Así que, básicamente, uno podría verlo de esta manera: una herramienta de rouge le ha permitido al usuario crear un archivo al que no puede acceder una gran cantidad de Windows (por ejemplo, Explorer). Podría opinar que no debería tener que lidiar con esto.
(Por otro lado, esto no es un voto de aprobación para una longitud de ruta máxima corta: creo que 260 caracteres es una broma, solo digo que si el shell de Windows y algunas API no pueden manejar> 260 entonces ¿por qué debería? ?).
Entonces, ¿es esta una vista justa? ¿Debería decir "No es mi problema"?
ACTUALIZACIÓN: Acabo de tener otro usuario con el mismo problema. Esta vez un archivo mp3. ¿Me estoy perdiendo de algo? ¿Cómo pueden estos usuarios crear archivos que violan la regla MAX_PATH?
Como mencionó, muchas de las funciones del Shell de Windows solo funcionan en rutas de hasta MAX_PATH. Windows XP y yo creemos que Vista tiene problemas en el Explorador al anidar directorios con nombres largos de archivos. No revisé Windows 7, quizás lo arreglaron. Desafortunadamente, esto significa que los usuarios tienen dificultades para explorar estos archivos.
Si realmente desea admitir rutas largas, deberá verificar las funciones que esté utilizando en Shell32.dll que tomen rutas para garantizar que admitan rutas largas. Para aquellos que no lo hagan, tendrás que escribirlos tú mismo usando las funciones de Kernel32.
Si decide utilizar Shell32 y se limita a MAX_PATH, sería aconsejable escribir su código para admitir rutas de archivos largas. Si Microsoft más tarde cambia Shell32 (o crea una alternativa), estará mejor posicionado para agregar soporte para ellos.
Solo para agregar otro par de dimensiones al problema, recuerde que los nombres de archivo son UTF-16, y puede encontrar sistemas de archivos que no sean NTFS o FAT que pueden ser sensibles a mayúsculas y minúsculas.
Esta limitación se basa en una gran cantidad de software escrito en C o C ++. Incluyendo el código MSFT, aunque lo han estado reduciendo. Es solo parcialmente una limitación de Win32, todavía tiene un límite superior duro en la longitud de un nombre de archivo (no de ruta) a través de WIN32_FIND_DATA, por ejemplo. Una razón por la que incluso .NET tiene restricciones de longitud . Esto no va a desaparecer pronto, Win32 sigue siendo fuerte y la cadena C de la Edad de Piedra no desaparecerá.
Su cliente tendrá poca simpatía con él, sin duda, probablemente hasta que pueda mostrarle otro programa que falla de la misma manera. Sin embargo, asegúrese de que su código pueda detectar de manera confiable el posible desbordamiento del búfer de cadenas, seguido de un diagnóstico razonable. Sin simpatía por los programas que bombardean la corrupción del montón.
Las rutas a menudo pueden ser más grandes que 260, un ejemplo sería cuando los enlaces simbólicos se anidan y se repiten una y otra vez, incluso a propósito. Creo que los programadores deberían pensar si quieren que su programa maneje estos caminos terriblemente grandes o no. IMO, 260 tiene MUCHO espacio, pero así soy yo. Mi respuesta a esto es:
si tiene que preguntarse tan profundamente sobre la ruptura del límite de 260 caracteres, entonces es probable que sea lo que debe hacer. A menudo buscamos confirmación cuando estamos a punto de hacer algo de lo que no estamos seguros ...
Creo que la ruta máxima en cualquier parte de la API es de aproximadamente 32k de longitud, pero eso depende de usted. De vuelta en el día fue un gran cambio (¡la mitad de un segmento de memoria completo! ¡Sheesh!) Pero hoy en día, en el entorno de direccionamiento transparente de segmento en el que vivimos, donde toda la memoria se acumula en el piso, 32k es nada ... Las rutas de AFAIK no necesitarían ser tan largas a menos que estés usando un lenguaje unicode sofisticado que requiera muchos otros personajes, etc., etc. podríamos hablar sobre esto todo el día pero ya entendiste la idea. Espero que esto ayude ... o duela?
No es estrictamente una respuesta a su pregunta específica, pero podría ayudar a aquellos que sí necesitan manejar nombres largos de archivos.
La biblioteca de Delimon es una biblioteca basada en .NET Framework 4 en Microsoft TechNet para superar el problema de los nombres de archivo largos:
Biblioteca Delimon.Win32.I O (V4.0) .
Tiene sus propias versiones de métodos clave de System.IO. Por ejemplo, reemplazarías:
System.IO.Directory.GetFiles
con
Delimon.Win32.IO.Directory.GetFiles
que te permitirá manejar archivos y carpetas largos.
Desde el sitio web:
Delimon.Win32.IO reemplaza las funciones básicas de archivos de System.IO y admite nombres de archivos y carpetas de hasta 32,767 caracteres.
Esta biblioteca está escrita en .NET Framework 4.0 y se puede usar en sistemas x86 y x64. Las limitaciones de archivos y carpetas del espacio de nombres System.IO estándar pueden funcionar con archivos que tienen 260 caracteres en un nombre de archivo y 240 caracteres en un nombre de carpeta (MAX_PATH generalmente se configura como 260 caracteres). Normalmente se encuentra con el error System.IO.PathTooLongException con la Biblioteca .NET estándar.
No es un problema real. NTFS admite nombres de archivos de hasta 32K ( 32.767 caracteres de ancho ). Solo necesita utilizar la API correcta y corregir la sintaxis de los nombres de archivo. La regla base es: el nombre de archivo debería comenzar con ''//?/' (Ver http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx ) como //?/C:/Temp . La misma sintaxis que puede usar con UNC: //?/UNC/Server/share/Path . Es importante entender que puede usar solo un pequeño subconjunto de funciones API. Por ejemplo, mire la descripción de funciones de MSDN
CreateFile
CreateDirectory
MoveFile
y así
encontrará texto como:
En la versión ANSI de esta función, el nombre está limitado a caracteres MAX_PATH. Para extender este límite a 32.767 caracteres de ancho, llame a la versión Unicode de la función y anteponga "/? /" A la ruta. Para obtener más información, vea Nombrar un archivo.
Esto funciona de forma segura. Si tiene un manejador de archivo desde CreateFile puede usar todas las demás funciones utilizadas hFile ( ReadFile , WriteFile , etc.) sin ninguna restricción.
Si escribe un programa como un escáner de virus o software de copia de seguridad o algún buen software que se ejecute en un servidor, debe escribir su programa para que todas las operaciones de archivo admitan nombres de archivo de hasta 32K caracteres y no MAX_PATH .
Sus propias API no deben codificar un límite fijo en la longitud de la ruta (o cualquier otro límite estricto); sin embargo, no debe violar las condiciones previas de las API del sistema para realizar alguna tarea. En mi humilde opinión, el hecho de que Windows limite la longitud de los nombres de las rutas es absurdo y debería considerarse un error. Dicho esto, no, le sugiero que no intente utilizar las distintas API del sistema que no sean las documentadas, incluso si eso da lugar a cierto comportamiento no deseado, como los límites a la longitud máxima de la ruta. Entonces, en resumen, su punto de vista es completamente justo; si el sistema operativo no lo admite, el sistema operativo no lo admite. Dicho esto, es posible que desee dejar en claro a los usuarios que esta es una limitación de Windows y no de su propio código.
Tengo una programación en C y estaba buscando la forma de obtener la longitud máxima de un nombre de archivo dado, después de buscar MAX_PATH, tropecé con este hilo y, después de algunas reflexiones sobre este tema, y después de leer los comentarios sobre este hilo, tengo llegar a la siguiente conclusión.
Así que entiendo que NTFS admite nombres de archivo de hasta 32.767 caracteres, sin embargo, de acuerdo con el conocimiento FAT16 solo admite nombres de archivos de 11 caracteres, 8 + 3, así que en realidad los sistemas operativos deberían tener una función que nuestro programa pueda llamar para eliminar el tamaño máximo del archivo , simplemente porque todos los sistemas de archivos tienen diferentes limitaciones, incluida la longitud del nombre del archivo.
Entonces, la conclusión final debe ser que, dado que nosotros, los desarrolladores, no sabemos nada sobre en qué sistema de archivos se almacenarán los datos, entonces la única solución debe ser un método de prueba y error.
Una forma sencilla de cómo estos archivos con rutas largas podrían crearse incluso con software que no admita rutas más largas que MAX_PATH: mediante un recurso compartido de archivos.
Ejemplo:
"C: / My veeeeeeeeeeeeeeeeeeeeery looooooooooooooooooong folder" podría compartirse como "datos". Los usuarios podrían acceder a esa carpeta a través de la ruta UNC // computadora / datos o (incluso más corto) a través de una letra de unidad (M: /) suponiendo que M: está mapeada a // computadora / datos.
Esto sucede a menudo en los servidores de archivos.