Dev Faq
9
votes

N'importe quel moyen de contourner la pathatrietoolongexception que FileSysteminfo.fullName jette parfois?

J'ai des fichiers sur mon disque dur qui jette un pathToolongexception lorsque j'accède à la propriété FULLNAME d'un objet FileSysteminfo objet. Y a-t-il un moyen autour de cela (à l'exclusion de la renommée des fichiers qui n'est pas une option)?

http://msdn.microsoft .com / fr-nous / bibliothèque / aa365247% 28Vs.85% 29.aspx # maxpath mentionné par d'autres réponses suggère de mettre un préfixe "\? \" sur le nom du fichier, mais dans ce cas, le DistoireIfo .GetFileSysteminfos () est responsable de la création du FileSysteminfo des objets et DistoireIfo n'accepte pas ce préfixe afin qu'il n'y a aucun moyen de l'utiliser.

la réponse " PathToolonGException dans C # Code " ne vous aide pas parce que Il s'agit d'une application multi-threadée et je ne peux pas continuer à changer le chemin d'application actuel.

Dois-je vraiment tout faire avec Pinvoke juste pour pouvoir lire chaque fichier sur le disque dur?

1 commentaires

Avez-vous essayé: codeProject.com/kb/files/longfilenames.aspx ?

4 Réponses :

2
votes

Il n'y a pas beaucoup de programmes qui peuvent survivre à un chemin de plus de 259 caractères. Limite assez difficile pour la couche Winapi, max_path est partout. Il a été considéré pour .NET mais sans résultats concrets. Blog post Series se termine ici avec des liens vers des entrées précédentes en bas.

0 commentaires
3
votes

Ceci semble intéressant ... wrapper de chemin longue Codepex

Le wrapper long chemin fournit des fonctionnalités permettant de fonctionner plus facilement avec des chemins plus longs que la limite de 259 caractères actuelle de l'espace de noms System.IO. En utilisant les classes de chemin longue, les projets peuvent désormais utiliser des chemins jusqu'à 32 000 caractères.

Je vais essayer d'essayer, bien que je notez immédiatement, il ne fournit pas de méthode équivalente à distoireInfo.getfilesysteminfos () afin que cela aura besoin de modification.

0 commentaires
2
votes

Travailler correctement avec de longues chemins n'est pas si difficile - Setacl le fait-il, par exemple. Mais:

  • Les classes .NET Framework ne supporte pas de longues chemins afin que vous ne puissiez pas les utiliser
  • Vous devez écrire une enveloppe pour chaque fonction d'API système de fichiers afin qu'elle utilise le bon chemin correct à la fois pour les chemins locaux et UNC

    Voici la documentation sur MSDN sur les chemins longs: http://msdn.microsoft.com/en-us/library/aa365247 (v = vs.85) .aspx

0 commentaires
4
votes

AS de Windows 10 (ou Windows Server 2016) et .NET 4.6.2, les chemins longs peuvent être pris en charge directement si un paramètre de registre est activé et que votre application est marquée comme étant "Cays-dure longue".

Le paramètre est accessible via l'éditeur de stratégie de groupe local ( gpedit.msc code>), sous Configuration de l'ordinateur strong> > Tous les paramètres strong>> Activer les chemins de longs Win32 forts> p>

afin de marquer votre application en tant que "PROPRÈRE LONGRE au courant", ajoutez cette section à votre fichier manifeste: p> 

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" />
  </runtime>
</configuration>

0 commentaires

Articles qui pourrait vous intéresser :

Calculer la différence dans l'échelle d'évaluation alphabétique
Ignorer la propriété de l'interface utilisateur Swagger
Comment détruire les éléments dynamiques du panneau dans le script Unity C #
Entity Framework Core 3.1 avec NetTopologySuite.Geometries.Point: SqlException: la valeur fournie n'est pas une instance valide de la géographie du type de données