Dois-je traiter avec les fichiers de plus de MAX_PATH?

Juste eu un cas intéressant.

Mon logiciel rapporté une défaillance causée par un chemin plus long que MAX_PATH.

Le chemin était juste un simple vieux document dans Mes Documents, par exemple:

C:\Documents and Settings\Bill\Some Stupid FOlder Name\A really ridiculously long file thats really very very very..........very long.pdf

Longueur totale de 269 caractères (MAX_PATH==260).

L'utilisateur n'était pas à l'aide d'un disque dur externe ou quelque chose comme ça. Ce fut un fichier sur un Windows gérés en voiture.

Donc ma question est celle-ci. Dois-je prendre soin?

Je ne dis pas peut je traiter avec les longs chemins, je me demande devrait I. Oui je suis au courant de le "\?\" unicode hack sur certaines Api Win32, mais il semble que ce hack n'est pas sans risque (comme c'est un changement de comportement de la façon dont l'Api analyser des chemins) et n'est pas pris en charge par toutes les Api .

Quoi qu'il en soit, permettez-moi de ma position/affirmations:

  1. Premier sans doute la seule façon de l'utilisateur a été en mesure de briser cette limite est de savoir si l'application elle a utilisé usages spéciaux Unicode hack. C'est un fichier PDF, donc peut-être que l'outil de PDF elle a utilisé utilise ce hack.
  2. J'ai essayé de reproduire ce (à l'aide de l'unicode hack) et expérimenté. Ce que j'ai trouvé était que, bien que le fichier s'affiche dans l'Explorateur, je ne peux rien faire avec elle. Je ne peux pas l'ouvrir, je ne peux pas choisir "Propriétés" (Windows 7). D'autres applications ne pouvez pas ouvrir le fichier (par exemple, IE, Firefox, Notepad). L'explorateur ne permettez-moi de créer des fichiers/répertoires qui sont trop long il refuse juste. Idem pour l'outil de ligne de commande cmd.exe.

Donc en gros, on pourrait regarder cela de cette façon: un rouge outil permet à l'utilisateur de créer un fichier qui n'est pas accessible par un grand nombre de Fenêtres (par exemple, l'Explorateur). J'ai pu prendre le point de vue que je ne devrais pas avoir à traiter avec cela.

(En aparté, ce n'est pas un vote d'approbation pour une courte max longueur du chemin: je pense 260 caractères est une blague, je dis juste que si le shell Windows et certaines Api ne peut pas gérer > 260 alors pourquoi devrais-je?).

Cette dernière est-elle fidèle? Devrais-je dire "Pas mon problème"?

Mise à JOUR: Juste eu un autre utilisateur avec le même problème. Cette fois, un fichier mp3. Ai-je raté quelque chose? Comment ces utilisateurs de créer des fichiers qui enfreignent la MAX_PATH règle?

  • Il est facile de créer un fichier dont le nom est trop long: il suffit de renommer l'un de ses ancêtre des répertoires d'être assez long à faire basculer le fichier sur le bord. Dans votre exemple: rename "C:\Documents and Settings\Bill\New Folder" "Some Stupid FOlder Name".
InformationsquelleAutor John | 2010-05-13
  1. 12

    Ce n'est pas un réel problème. NTFS soutenir les noms de fichiers jusqu'à 32K (de 32 767 caractères larges). Vous avez seulement besoin de l'utilisation correcte de l'API et de corriger la syntaxe des noms de fichiers. La base de la règle est: le nom de fichier doit commencer par '\\?\' (voir http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx) comme \\?\C:\Temp. La même syntaxe que vous pouvez utiliser avec UNC: \\?\UNC\Server\share\Path. Important de comprendre que vous pouvez utiliser seulement un petit sous-ensemble de la fonction de l'API. Par exemple chercher à MSDN description des fonctions

    CreateFile
CreateDirectory 
MoveFile

    et ainsi de suite

    vous trouverez le texte comme :

    Dans la version ANSI de cette fonction,
    le nom est limité à MAX_PATH
    des personnages. Pour étendre cette limite
    De 32 767 caractères larges, appelez le
    La version Unicode de la fonction et
    ajouter le préfixe "\?\" le chemin d'accès. Pour plus d'
    d'informations, voir nommer un Fichier.

    Cette fonctions que vous pouvez utiliser en toute sûreté. Si vous avez un descripteur de fichier à partir de CreateFile vous pouvez utiliser toutes les autres fonctions utilisées hFile (ReadFile, WriteFile etc.) sans aucune restriction.

    Si vous écrivez un programme comme le scanner de virus ou de logiciels de sauvegarde ou du bon logiciel s'exécutant sur un serveur, vous devez écrire votre programme de sorte que toutes les opérations sur les fichiers de soutenir les noms de fichiers jusqu'à 32K caractères et pas MAX_PATH caractères.

    • Salut merci pour le commentaire. Oui, je me rends compte de ces il existe des Api (voir mon post). Je ne pense pas que l'on peut commencer à utiliser ce hack et attendre que tout se passe en douceur. Par exemple, le \\?\ hack enlève une partie de l'analyse. Aussi, il n'est pas clair pour moi comment la SORTIE de l'Api est affecté. C'est juste pas assez clair pour moi, quel est l'impact de ce hack. Si je vais vers le bas de cette route, je vais avoir à faire beaucoup de tests. Avez-vous une expérience de l'utilisation de ces Api?
    • Vous ne comprenez pas comment le avec “\\?\” des œuvres. Il est PAS un hack! Il est bien documenté façon de travailler la plupart du temps directement avec Natif de Windows NT de l'API (à partir de ntdll.dll) comme NtCreateFile msdn.microsoft.com/en-us/library/bb432380%28VS.85%29.aspx. Si vous utilisez cette fonctionnalité, vous recevrez pas moins de sécurité, mais seulement moins de confort. La plupart des API Windows proviennent de l'époque de la 16-bits de Windows 3.0 et ont MAX_PATH restriction. Le Natif de Windows NT de l'API (à partir de ntdll.dll) principalement utilisé pour la programmation du pilote. Ainsi, l'utilisation de “\\?\” est sûr. J'ai plus de 15 ans d'expérience de l'utilisation de ce.
    • OK oui "hack" est probablement le mauvais terme 🙂 Ce que je veux dire, cependant, est qu'il n'est PAS seulement un support de remplacement. Par exemple, les chemins relatifs ne fonctionne pas, si vous utilisez "." ou ".." dans un chemin qu'il ne fonctionne pas. Certaines Api permettra également de changer la SORTIE d'utiliser cette "fonctionnalité" (par exemple des GetLongPathName() va retourner des chemins qui comprennent le "\\?\"). D'autre part, il est bon d'entendre que vous avez eu 15 ans d'expérience de l'utilisation de cette API - qui soulage mon esprit beaucoup.
    • C'est la réponse correcte. Prenons un cas simple de déplacer un répertoire avec tous les enfants dans un autre répertoire que se cogne contre la MAX_PATH limite. Devriez-vous simplement de ne pas tous les fichiers qui ne rentre pas dans C:\myreallylong\stupid\directoryname\thatiwant\torestore\myoldbackups\tothisannoying\reallylongpath? 😉
    • La préfixation des chemins d'accès UNC que \\?\accueil\share ne fonctionne PAS. Vous devez utiliser \\?\UNC\host\share.
    • Merci pour la fixation de l'élément d'erreur. Je suis content que l'on continue à lire les anciens post. :-). Le lien à la documentation MSDN qui j'ai parlé il y a 4 ans encore du travail. En contient beaucoup d'autres noms (\\.\CdRomX, \\.C:, \\.\PhysicalDiskX, \\?\GLOBALROOT et ainsi de suite). Je voulais simplement pointer vers la possibilité de rompre MAX_PATH limite et de montrer que l'utilisation est vraiment facile.

    InformationsquelleAutor Oleg
  2. 10

    Cette limitation est cuit dans un beaucoup de logiciels écrits en C ou C++. Y compris MSFT code, bien qu'ils aient été s'éloigner de lui. Il n'est que partiellement une limitation Win32, elle a toujours une limite haute sur la longueur d'un nom de fichier (pas de chemin d'accès) à travers WIN32_FIND_DATA par exemple. L'une des raisons de cette même .NET a des restrictions de longueur de. Ce n'est pas pour demain, Win32 est toujours aussi fort et l'âge de la pierre, chaîne C ne disparaîtra pas.

    Votre client aura peu de sympathie avec elle, pas de doute, probablement jusqu'à ce que vous pouvez leur montrer un autre programme qui échoue de la même façon. Cependant, assurez-vous que votre code de manière fiable peut détecter le potentiel de la chaîne de débordement de la mémoire tampon, suivi par un délai raisonnable de diagnostic. Pas de sympathie pour les programmes de bombardement sur la corruption de segment.

    • Salut Hans, merci pour la réponse. Vous êtes de m'aider sur un couple de questions en ce moment! Merci!
    InformationsquelleAutor Hans Passant
  3. 6

    Comme vous l'avez mentionné beaucoup de l'environnement Windows fonctions ne fonctionnent que sur des chemins à MAX_PATH. Windows XP et je crois que Vista, les deux ont des problèmes dans l'Explorateur lors de l'imbrication de répertoires avec des noms de fichiers longs. Je n'ai pas vérifié Windows 7 - ils ont peut-être résolu. Ce qui malheureusement signifie que les utilisateurs ont un moment difficile de navigation de ces fichiers.

    Si vous voulez vraiment soutenir à long des chemins, vous aurez besoin de vérifier toutes les fonctions que vous utilisez dans Shell32.dll qui prennent des chemins pour s'assurer qu'ils appuient long des chemins. Pour ceux qui ne vous aurez à utiliser les écrire vous-même à l'aide de Kernel32 fonctions.

    Si vous décidez d'utiliser Shell32 et être limitée à MAX_PATH, l'écriture de votre code à l'appui long des chemins de fichiers serait souhaitable. Si Microsoft à changer plus tard Shell32 (ou une autre), vous serez en meilleure position pour ajouter de l'aide pour eux.

    Juste pour ajouter un autre couple de dimensions du problème, n'oubliez pas que les noms de fichiers sont en UTF-16, et vous pouvez rencontrer non NTFS ou FAT systèmes de fichiers qui peuvent être sensibles à la casse!

    • Oui Windows 7 shell est toujours le même. Non seulement il vous empêcher de créer des fichiers/dossiers trop long, mais si elle arrive à en trouver un qui existe, vous ne pouvez pas faire quelque chose avec elle (peut même pas supprimer!)
    • Merci pour la vérification, bon de savoir ce que 7 est capable de faire, bien que décevant de constater qu'il souffre de la même restriction.
    InformationsquelleAutor Stephen Nutt
  4. 5

    Votre propre Api ne doit pas coder en dur une limite fixe sur toute la longueur du chemin (ou tout autre dur limites); toutefois, vous ne devez pas violer les conditions préalables de l'Api du système dans le but d'accomplir une tâche. À mon humble avis, le fait que Windows limite la longueur des noms de chemin d'accès est absurde et doit être considéré comme un bug. Cela dit, non, je vous suggère de ne pas tenter d'utiliser les différentes Api d'un système autre que comme documenté, même si cela se traduit dans certains undesireable comportement tels que les limites de la longueur maximale de chemin. Donc, en résumé, votre point de vue est tout à fait juste; si le système d'exploitation ne le supporte pas, alors le système d'exploitation ne le supporte pas. Cela dit, vous pouvez faire comprendre aux utilisateurs que c'est une limitation de Windows et n'est pas de votre propre code.

    InformationsquelleAutor Michael Aaron Safyan
  5. 2

    Un moyen facile comment ces dossiers avec de longs chemins pourraient être créés, même par un logiciel qui ne prend pas en charge les chemins d'accès de plus de MAX_PATH: par le biais d'un partage de fichiers.

    Exemple:

    "C:\My veeeeeeeeeeeeeeeeeeeeery looooooooooooooooooong dossier" pourrait être partagé en tant que "données". Les utilisateurs pouvaient alors accéder à ce dossier par le chemin d'accès UNC \\ordinateur\data ou (encore plus court) à travers une lettre de lecteur (M:\) en supposant que M: est mappé à \\ordinateur\data.

    Ce qui arrive souvent sur les serveurs de fichiers.

    InformationsquelleAutor Helge Klein
  6. 1

    Chemins, souvent, peut-être plus de 260, par exemple, quand des liens symboliques obtenir imbriquées et répéter encore et parfois même sur le but. Je pense que les programmeurs doivent réfléchir s'ils veulent que leur programme pour gérer ces incroyablement grands chemins ou pas. OMI, 260, c'est l'ABONDANCE de l'espace, mais c'est juste moi. Ma réponse à cette question est:

    si vous devez demander vous-même si profondément au sujet de la rupture de l'260 char limite, alors c'est probablement ce que vous devez faire. On a souvent l'air de confirmation lorsque nous sommes sur le point de faire quelque chose que nous n'êtes pas sûr au sujet de...

    Je pense que le maximum de chemin d'accès de n'importe où dans l'API est d'environ 32k long, mais c'est à vous de voir. Retour dans la journée qui était un assez gros morceau de changement (la moitié de l'ensemble d'un segment de mémoire!! sheesh!) mais aujourd'hui, dans le segment-transparent aborder l'environnement dans lequel nous vivons, où toute la mémoire est amassé sur le plat, 32k est nothin'... autant que je sache, les chemins n'auraient pas besoin d'être que long, sauf si vous utilisez un peu de fantaisie langage unicode qui nécessite beaucoup d'autres personnages, etc, etc.. nous pourrions vous en parler toute la journée, mais vous voyez l'idée. J'espère que cela aide..... ou mal?

    InformationsquelleAutor
  7. 1

    Je suis doung certains programmation en C et j'étais à la recherche d'un moyen d'obtenir la longueur maximale d'un nom de fichier donné, après une recherche de MAX_PATH je suis tombé à ce fil, et après som pensées sur ce sujet et après avoir lu les commentaires sur ce fil, j'en suis venu à la conclusion suivante.

    Donc, je comprends que NTFS soutenir les noms de fichiers jusqu'à 32.767 caractères, cependant, selon les connaissances FAT16 seulement de support à 11 caractères des noms de fichiers, 8 + 3, donc dans reallity systèmes d'exploitation doit avoir une fonction qui notre programme peuvent faire appel à dertemine le nom de fichier maximum la taille, tout simplement parce que tous les systèmes de fichiers ont des limites différentes, y compris la longueur du nom de fichier.

    De sorte que la fin de la conclusion doit être que, puisque nous, les développeurs, ne sais rien à propos de laquelle le système de fichiers de données vont être stockées, donc la seule solution que doit être un essai et d'erreur de méthode.

    InformationsquelleAutor Ivo Santos
  8. 0

    Pas strictement une réponse à votre question, mais cela pourrait aider ceux qui doivent gérer les noms de fichiers longs.

    La Delimon bibliothèque est un .NET Framework 4 en fonction de la bibliothèque sur le site de Microsoft TechNet pour surmonter les noms de fichiers longs problème:

    Delimon.Win32.IO Bibliothèque (V4.0).

    Il a ses propres versions des principales méthodes de Système.IO. Par exemple, vous devez remplacer:

    Système.IO.Répertoire.GetFiles

    avec

    Delimon.Win32.IO.Répertoire.GetFiles

    qui vous permettra de manipuler des fichiers et des dossiers.

    À partir du site web:

    Delimon.Win32.IO remplace le fichier de base des fonctions du Système.IO et
    prend en charge le Fichier & les noms de Dossier jusqu'à jusqu'à 32 767 Caractères.

    Cette Bibliothèque est écrit sur .NET Framework 4.0 et peut être utilisé
    sur x86 & systèmes x64. Le Fichier & Dossier limitations de la norme
    Système.IO espace de noms peut travailler avec des fichiers qui ont plus de 260 caractères dans un
    nom de fichier et de 240 caractères dans un nom de dossier (MAX_PATH est généralement
    configuré en tant que 260 caractères maximum). Généralement vous exécutez dans l'
    Système.IO.PathTooLongException Erreur avec le Standard .NET-Library.

    InformationsquelleAutor TripleAntigen