FileSystemWatcher: Chemin d'accès trop long fait planter mon programme.

Version imprimable

Bonsoir à tous,
Pouvez vous m'aider à corriger un bug ? Je traîne celui-ci depuis 2 ans et j'ai enfin décider d'y regarder de plus prêt :
J'ai grosso-modo un plantage par jour et pour vérifier j'ai placé un bloc Try/Catch et tracé l'erreur vers mon fichier trace.log.
Donc forcement je n'ai plus de plantage mais en contre partie je ne traite pas l'exception : Visiblement il s'agit de chemin trop long qui sont interceptés par FileSystemWatcher.

Déjà je m’étonne que FileSystemWatcher puisse voir ce genre de chemin mais admettons. Ce qui m’étonne aussi c'est que FileSystemWatcher vois des chemins avec des noms de dossiers tronqués avec des "~" : du style "M:\Mon Chem~Trop Long" pour "M:\Mon Chemin Est Trop Long" par exemple.
Pour moi ces chemins ne sont pas valide donc je n'ai aucune raison de les traiter mais je serais très intéressé d'avoir votre avis sur la question si vous avez déjà été confronté au problème.

Voici ce que mon trace.log me dit (voir lignes 40158 et 40166) :

Citation:

[40153] 11:01:56 587 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\11F3DF40.tmp" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>
[40154] 11:01:56 754 -Verbose- [X_project.modFswTag/ UpdatePaths] => L'extension du fichier "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\11F3DF40.tmp" est rejetée par le filtre, celui-ci est ignoré par UpdatePath
[40155] 11:01:57 75 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\11F3DF40.tmp" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>
[40156] 11:01:57 216 -Verbose- [X_project.modFswTag/ UpdatePaths] => L'extension du fichier "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\11F3DF40.tmp" est rejetée par le filtre, celui-ci est ignoré par UpdatePath
[40157] 11:01:57 528 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\E195D641.tmp" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>
[40158] 11:01:57 871 -Critical- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin d'accès spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier qualifié complet doit comprendre moins de*260*caractères et le nom du répertoire moins de 248*caractères. à System.IO.PathHelper.Append(Char value)
à System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
à System.IO.Path.GetPathRoot(String path)
à System.IO.RenamedEventArgs.get_OldFullPath()
à X_project.modFswTag.PathInfos..ctor(FileSystemEventArgs e)
à X_project.modFswTag.ProcessFileSystemEvents()
[40159] 11:01:57 871 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\E195D641.tmp" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>
[40160] 11:01:58 27 -Verbose- [X_project.modFswTag/ UpdatePaths] => L'extension du fichier "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\E195D641.tmp" est rejetée par le filtre, celui-ci est ignoré par UpdatePath
[40161] 11:01:58 27 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\11F3DF40.tmp" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>
[40162] 11:01:58 167 -Verbose- [X_project.modFswTag/ UpdatePaths] => L'extension du fichier "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\11F3DF40.tmp" est rejetée par le filtre, celui-ci est ignoré par UpdatePath
[40163] 11:01:58 167 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>
[40164] 11:01:58 323 -Verbose- [X_project.modFswTag/ UpdatePaths] => Un attribut du dossier "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2" a changé, celui-ci est ignoré par UpdatePath
[40165] 11:01:58 323 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\9505-FDT-509 FE SSI Phase 1 Câbles Arret Technique COM2 BUS2 Local SD45.doc" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>
[40166] 11:01:58 464 -Critical- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin d'accès spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier qualifié complet doit comprendre moins de*260*caractères et le nom du répertoire moins de 248*caractères. à System.IO.PathHelper.Append(Char value)
à System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
à System.IO.Path.GetFullPathInternal(String path)
à System.IO.FileInfo.Init(String fileName, Boolean checkHost)
à System.IO.FileInfo..ctor(String fileName)
à X_project.modFswTag.PathInfos..ctor(FileSystemEventArgs e)
à X_project.modFswTag.ProcessFileSystemEvents()
[40167] 11:01:58 464 -Verbose- [X_project.modFswTag/ ProcessFileSystemEvents] => Le chemin "M:\AAQ2~4.095\2-Etudes\DT4~1.85-\2-3DOE~1\5CERTI~1\5FB1F~1.2FI\FICHED~2\9505-FDT-509 FE SSI Phase 1 Câbles Arret Technique COM2 BUS2 Local SD45.doc" (stocké dans le buffer par FsWatcher) va être traité par le thread [9] <ProcessFileSystemEventsArg>

L'objet _fileSystemEvents alimenté par les événements de FileSystemWatcher :

Code:

Private _fileSystemEvents As New ConcurrentQueue(Of FileSystemEventArgs)()

La procédure ou j'ai mis un bloc Try / Catch :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Module modFswTag ...... Private Sub ProcessFileSystemEvents() Thread.CurrentThread.Name = ("ProcessFileSystemEventsArg") While Not _stopRequested Dim e As FileSystemEventArgs = Nothing ' Traiter l'évènement '''' If _fileSystemEvents.TryDequeue(e) Then Mysource1.TraceEvent(TraceEventType.Verbose, 0, String.Format("Le chemin ""{0}"" (stocké dans le buffer par FsWatcher) va être traité par le thread [{1}] <{2}>", e.FullPath, Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.Name)) Try Dim PathInfo As New PathInfos(e) UpdatePaths(PathInfo) Catch ex As Exception Mysource1.TraceEvent(TraceEventType.Critical, 0, ex.Message & ex.StackTrace) End Try Else ' rien dans la file, on attend un peu Thread.Sleep(50) End If End While End Sub ...... End Module
Ma classe ou visiblement se produit l'erreur :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Module modFswTag ...... Public Class PathInfos Public Sub New(ByVal e As FileSystemEventArgs) Select Case e.ChangeType Case WatcherChangeTypes.Changed _EventType = EventsTag.FswChanged Case WatcherChangeTypes.Created _EventType = EventsTag.FswCreated Case WatcherChangeTypes.Deleted _EventType = EventsTag.FswDeleted Case WatcherChangeTypes.Renamed _EventType = EventsTag.FswRenamed End Select _Fi = New FileInfo(e.FullPath) GetInfos(_Fi) _Path = e.FullPath _OldPath = Nothing If TypeOf (e) Is RenamedEventArgs Then Dim e1 As RenamedEventArgs = CType(e, RenamedEventArgs) _OldPath = e1.OldFullPath End If End Sub ...... End Class ...... End Module
Merci beaucoup, pour votre réponse.

16/06/2015, 21h37
clementmarcotte

Bonjour,

Citation:

Envoyé par BasicZX81

Bonsoir à tous,
Déjà je m’étonne que FileSystemWatcher puisse voir ce genre de chemin mais admettons. Ce qui m’étonne aussi c'est que FileSystemWatcher vois des chemins avec des noms de dossiers tronqués avec des "~" : du style "M:\Mon Chem~Trop Long" pour "M:\Mon Chemin Est Trop Long" par exemple.
Pour moi ces chemins ne sont pas valide donc je n'ai aucune raison de les traiter mais je serais très intéressé d'avoir votre avis sur la question si vous avez déjà été confronté au problème.

Ce sont des fichiers valides. C'est un héritage de l'époque où MS-DOS limitait les noms de fichiers à 8 caractères + l'extension. Quand Microsoft a fait sauter la limite des 8 caractères (Windows 95, si mes souvenirs sont exacts), ils ont conçu ce système pour préserver la compatibilité avec les anciennes versions de Windows. Donc chaque chemin d'accès "Windows" a automatiquement un équivalent "DOS" raccourci. Et en principe VB.net est capable de traiter les deux types de noms. Mais là, comme cela, il faudrait faire des recherches. Donc, théoriquement du moins, si ton nom "Windows" est trop long, et que nom "DOS" est assez court, tu pourrais l'utiliser à la place du nom "Windows"

Pour comparer les deux versions du nom de fichier, ou même du chemin d'accès, il y a un petit utilitaire gratuit sur CodePlex : PathCopyCopy
Il installe un menu contextuel dans l'Explorateur Windows (32 et 64 bits) et permet de copier différents types de chemins d'accès dans le presse-papiers.
16/06/2015, 22h27
BasicZX81

Merci beaucoup clementmarcotte,
En effet j'avais complètement oublié ces vieux vestiges de MS-DOS. On peux aussi faire un DIR /X depuis l'invite de commande pour afficher à la fois les noms longs et les noms courts ;) Voir ici : http://dos.heffge.fr/Le_dos_sied_noms.htm
Par contre j'ai un doute en cas d'homonymie et je ne sais pas comment reproduire la chose :
Si par exemple j'ai 2 noms longs qui conduisent à un homonyme, Windows va suffixé le nom du 1er dossier par ~1 et le 2eme par ~2

Juste pour l'exemple (j'ai pas vérifié ce que ça donne réellement en nom court et si l'exemple conduit à une homonymie) :
DossierAvecNomLong1 = Dossier~1
DossierAvecNomLong2 = Dossier~2

Si je supprime DossierAvecNomLong1, que va devenir le nom court de DossierAvecNomLong2 ?
17/06/2015, 07h02
BasicZX81

Citation:

Si je supprime DossierAvecNomLong1, que va devenir le nom court de DossierAvecNomLong2 ?

Bon, j'ai pu faire quelques tests. J'ignore comment Windows conserve les liens nom Long/ Nom Court mais un nom court sera toujours associé au même nom long, il n'y a pas de mélange et heureusement d'ailleurs ;)

EDIT : Sinon vous avez une idée de pourquoi j'ai une exception ? Certains chemins sont tronqués mais ils sont considérés comme trop long :weird:
17/06/2015, 20h41
clementmarcotte
Bonjour,

Citation:

Envoyé par BasicZX81

EDIT : Sinon vous avez une idée de pourquoi j'ai une exception ? Certains chemins sont tronqués mais ils sont considérés comme trop long :weird:

À première vue, tu as besoin de tester (au moins) deux choses:

La longueur totale du chemin d'accès, incluant, le fichier. (< 260 caractères)
La longueur du dossier sans le nom de fichier (< 248 caractères)

Les deux conditions semblent représenter, si on peut dire, un ET logique.

Je dirais aussi qu'avec ton bloc Try "combiné"
Code:

1 2 3 4 5 6 Try Dim PathInfo As New PathInfos(e) UpdatePaths(PathInfo) Catch ex As Exception Mysource1.TraceEvent(TraceEventType.Critical, 0, ex.Message & ex.StackTrace) End Try
Ce n'est pas vraiment évident de savoir si l'exception origine de ta classe, ou de UpdatePaths(); encore que tu connaisses ton code mieux que moi.

Cela n'engage que moi, mais je serais porté à faire deux blocs Try, ou peut-être que j'en mettrais un dans la classe elle-même.

Je suppose que de fins experts vont ajouter leur grain de sel.

P.S. Cela a plus ou moins rapport avec ton problème, mais je me suis souvenu d'une vieille affaire qui m'est déjà arrivée. J'avais développé une application de recherche de fichiers qui passait par FileInfo et DirectoryInfo, avec VB2005. Tout comme toi, je ramassais des exceptions de chemin d'accès trop long. Quand j'ai repris le programme avec VB2010, les mêmes erreurs étaient "éliminées" par VB. Bizarre quand même.
17/06/2015, 21h12
BasicZX81

Merci pour la réponse Clementmarcotte,
Alors j'ai bien vérifier mon code et pour moi l’exception ne peux pas venir de UpdatePaths(PathInfo) mais comme en matière d'informatique rien ne vaux un bon test réel je ferais l'essai avec un bloc Try au plus proche de l'exception.
En fait lorsque j'ai rajouté ce bloc Try avec la sortie du StackTrace sur le fichier trace.log je pensais que celui-ci m'aurais indiqué le numéro de la ligne en erreur mais non en fait....j'ai pas compris pourquoi :weird:.

Je dit peut-être une bêtise mais dans mon trace.log on retrouve 2 cas :

Citation:

à System.IO.RenamedEventArgs.get_OldFullPath()

semble indiquer que l'exception se situe sur la ligne

Code:

_OldPath = e1.OldFullPath

et

Citation:

à System.IO.FileInfo..ctor(String fileName)

semble indiquer que l'exception se situe sur la ligne

Code:

_Fi = New FileInfo(e.FullPath)

Peut-être que je devrais surveiller ces 2 lignes ? C'est d'ailleurs ce que je vais faire on verra bien.
18/06/2015, 19h24
BasicZX81

Bon, j'ai pas avancé beaucoup mais j'ai quelques pistes :

Je peux déjà confirmer que les exceptions se produisent sur les lignes que j'ai indiqués.

Ensuite il me semble qu'il doit y avoir une histoire avec les Threads :
Pour comprendre il faut savoir que je stocke tous les événements du FileSystemeWatcher dans une pile ConcurrentQueue à partir du Thread principal et je traite les événements de cette même pile dans un Thread secondaire.

Il peux donc s’écouler un léger Laps de temps entre ces 2 traitements. (Les traitements dans 2 Threads distincts en est certainement la cause aggravante mais je crois que j'aurais aussi le problème (dans une bien moindre mesure) si ces 2 traitements été synchrone).

En effet le File SystemWatcher peux voir un chemin à un instant t0 et ce même chemin peux ne plus exister à l'instant t1 (au moment du traitement) d'ou l'erreur sur cette ligne :

Code:

_Fi = New FileInfo(e.FullPath)

Pour le 2eme cas d'erreur j'en suis moins sûre mais à mon avis le problème est identique. Donc rien à voir avec le fait que ces chemins soit tronqués au format MS-DOS 8.3 il me semble, c'est sans doute un concours de circonstance.

Je pense laisser le Bloc Try / Catch pour ignorer ces chemins. Mais si vous avez une meilleur explication je suis preneur ;)