C# Comment puis-je résoudre les limitations lors de l'utilisation de DirectoryInfo?

Quand je récursive à travers des dossiers et des fichiers, je rencontre cette erreur:

Le chemin d'accès spécifié, le nom de fichier, ou les deux sont trop longs. Le nom de fichier complet doit être inférieure à 260 caractères, et le nom du répertoire doit être de moins de 248 caractères.

Voici ma fonction

private void ProcessDirectory(DirectoryInfo di)
{
    try
    {
        DirectoryInfo[] diArr = di.GetDirectories();

        foreach (DirectoryInfo directoryInfo in diArr)
        {
            if (StopCheck)
                    return;
            ProcessDirectory(directoryInfo);
        }
        ProcessFile(di);
    }
    catch (Exception e)
    {
        listBoxError.Items.Add(e.Message);
    }

    TextBoxCurrentFolder.Text = di.ToString();
}

Je ne peut pas créer le répertoire des noms plus courts, parce que je n'ai pas le droit de trop donc... Comment puis-je résoudre ce problème?

Ajouté:
Voici l'autre fonction:

private void ProcessFile(DirectoryInfo di)
{
    try
    {
        FileInfo[] fileInfo = di.GetFiles();

        if (fileInfo.LongLength != 0)
        {
            foreach (FileInfo info in fileInfo)
            {
                Size += info.Length;
                CountFile++;
            }
        }
    }
    catch (Exception e)
    {
        listBoxError.Items.Add(e.Message);
    }
}

MODIFIER
Trouvé où il a utilisé Zeta Longs trajets:
Comment puis-je utiliser la classe FileInfo, en évitant PathTooLongException?

Ont mis en œuvre, et maintenant, je vais laisser le programme exécuté au cours de la nuit pour voir si elle fonctionne.

MODIFIER
Utilisé le ZetaLongPath hier et il fonctionnait très bien! Il est même allé à travers les dossiers qui avaient besoin de l'autorisation d'accès.

MODIFIER
Au lieu de zetalongPath, j'ai utilisé Delimon.Win32.IO.dll je pense que c'est beaucoup mieux. Il a les mêmes interfaces que Win32.

Je suppose que vous devez retourner à la plaine de l'API Windows (FindFirst*/FindNext*)
Si l'erreur se produit de l'intérieur ProcessFile(), peut-être que le code peut être modifié si l'on peut les voir?
Vous savez que vous êtes le premier à le plus profond sous-dossier avant de commencer à traiter les fichiers?! Si vous souhaitez commencer avec la rootfolder vous devez déplacer ProcessFile(di); le début de la méthode.
Musefan: Non, le problème ne se produit pas. Bien sûr 🙂 ajout de la fonction
Tim: Oui, je sais, suis dit que je devrais commencer à partir de la plus profonde en premier.

OriginalL'auteur Phu Minh Pham | 2012-03-06

  1. 8

    Voici plus d'infos sur le Delimon bibliothèque mentionné plus haut. Son 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:

    System.IO.Directory.GetFiles

    avec 

    Delimon.Win32.IO.Directory.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.

    Heres une autre alternative appelée AlphaFS: github.com/alphaleonis/AlphaFS

    OriginalL'auteur TripleAntigen

  2. 1

    C'est une limitation connue sous Windows: http://msdn.microsoft.com/en-us/library/aa365247.aspx

    Je ne crois pas que vous serez en mesure d'obtenir autour d'elle, donc celui qui vous dit que vous n'êtes pas autorisé à faire plus court, vous aurez une assez solide argument pour expliquer pourquoi vous avez à.

    La seule vraie solution est de déplacer la profonde dossier quelque part d'autre, peut-être juste à la racine de votre lecteur.

    EDIT: en Fait il y a peut être une solution de contournement: http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html

    OriginalL'auteur Andy

  3. 1

    Vous pouvez utiliser le subst de commande. Il crée un lecteur virtuel commençant à n'importe quel dossier passé en paramètre.

    Par exemple, vous pouvez activer le chemin c:\aaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaa dans le lecteur R: et continuer à explorer les sous-dossiers de c:\aaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaa thru R:...

    Savez-vous ce que je veux dire?

    OriginalL'auteur Ignacio Soler Garcia

  4. 1

    Vous aurez à utiliser P/Invoke et la version Unicode de l'fonctions de l'API Win32. Vous aurez besoin FindFirstFile, FindNextFile et FindClose fonctions.

    Voir aussi:

    OriginalL'auteur ken2k

  5. 0

    Je recommande également la lecture de ce trois-partie post de blog de la BCL Équipe, publié en 2007, mais concernant spécifiquement les limites de DirectoryInfo quand il s'agit de dossiers profondément imbriqués. Il couvre l'histoire de la MAX_PATH limitation, la plus récente \?\ format de chemin d'accès, et les différentes .NET-solutions et des solutions de contournement.

    Complet, mais peut-être un peu daté.

    OriginalL'auteur Avner Shahar-Kashtan