Discussion :

[BasicZX81]

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) :

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

Private _fileSystemEvents As New ConcurrentQueue(Of FileSystemEventArgs)()

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[clementmarcotte]

Bonjour,

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.

[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 ?

[BasicZX81]

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

[clementmarcotte]

Bonjour,

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

À 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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 .

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

à System.IO.RenamedEventArgs.get_OldFullPath()

semble indiquer que l'exception se situe sur la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

_OldPath = e1.OldFullPath

et

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

semble indiquer que l'exception se situe sur la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

_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.

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

_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