DirectoryInfo => GetFiles = System.IO.__Error.WinIOError

Version imprimable

27/05/2013, 09h25
Sankasssss

DirectoryInfo => GetFiles = System.IO.__Error.WinIOError
Bonjour,

Mon collègue a un petit soucis dans son programme que nous n'arrivons pas à résoudre.

Le code suivant :
Code:

1 2 Dim di As New DirectoryInfo(savePath) For Each f As FileInfo In di.GetFiles("*.xls")
plante à la ligne 2 sur di.GetFiles avec cette erreur :

Citation:

StackTrace : at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler)
at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption)
at System.IO.DirectoryInfo.GetFiles(String searchPattern)
at SL0025VB.Main.main(String[] args)
Source : mscorlib

mais chose vraiment spéciale, il ne plante pas tout le temps. Si je le lance une fois, j'ai l'erreur et lors du deuxième lancement ça passe bien.

Le chemin vers le dossier stocké dans savePath est un chemin réseau vers notre serveur de fichier, sous le forme \\filesrv\data\RendezVousFichesB\ et nous nous sommes assuré qu'il était disponible à partir de la machine exécutant le logiciel et que notre utilisateur avait tous les droits sur ce dossier avant de le lancer.

Nous avons évidement cherché sur internet mais nous n'avons rien trouvé de similaire :?

Nous sommes donc preneur de toutes idées.

Merci d'avance.
27/05/2013, 09h33
_Ez3kiel

Aucun problèmes de droits sur le dossier ? Ou est-il en réseau ?
27/05/2013, 09h35
Sankasssss

Excuse j'ai édité mon message juste avant que tu ne répondes pour ajouter :

Citation:

Le chemin vers le dossier stocké dans savePath est un chemin réseau vers notre serveur de fichier, sous le forme \\filesrv\data\RendezVousFichesB\ et nous nous sommes assuré qu'il était disponible à partir de la machine exécutant le logiciel et que notre utilisateur avait tous les droits sur ce dossier avant de le lancer.

Donc non, pas de problème de droit et oui il est en réseau.
Mais chose bizarre, ça fonctionne très bien au deuxième lancement de l'application. :aie:
27/05/2013, 09h52
_Ez3kiel

Mmmmmh, parmis vos .xls vous n'en avez pas avec un nom (très très) long, qui donnerait un path supérieur au MAX_PATH ? :?

Dans le for each, vous ne faîtes pas de traitement de suppression d'.xls ?

Et le Message de l'exception dit quoi ?
27/05/2013, 10h10
Sankasssss

Dans la boucle on déplace les fichiers dans un autre répertoire mais ça plante avant ce déplacement.
Le message est :

Citation:

Message : Le chemin réseau n'a pas été trouvé.

StackTrace : at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler)
at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption)
at System.IO.DirectoryInfo.GetFiles(String searchPattern)
at SL0025VB.Main.main(String[] args)

Source : mscorlib

alors qu'il existe bien vu que nous avons ouvert un explorateur avec le dit chemin sur le serveur exécutant le programme. De plus il ne s'agit pas d'un lecteur réseau, on donne directement le chemin complet.

Ce qui est très embêtant, c'est que cette erreur ne se fait pas tous le temps, du coups nous avons vraiment du mal à l'isoler et à la comprendre...

P.S. : Merci de t’intéresser au problème.
27/05/2013, 10h44
_Ez3kiel

Citation:

Envoyé par Sankasssss

Dans la boucle on déplace les fichiers dans un autre répertoire mais ça plante avant ce déplacement.

Le fait de modifier la liste des .xls durant un for each sur cette dernière, n'altère-t-il pas le traitement ?
Oui j'ai bien dit le traitement, car en théorie, ça ne génère pas d'exception ... (Sauf si peut-être que dans notre cas ça nous donne un chemin réseau non valide pour avoir sauté un item, ou être repassé sur un item qui a déjà été déplacé ...)
Sans aucunes garanties, mais peut-être qu'un While serait plus convenant ?

Sinon, est-ce que l'appli a été testé sur d'autres posts ? (Le terme aléatoire me rappelle que mon poste bien que je sois dans le même groupe IIS que mes collègues me fait quelques réprimandes de sécurité quand il s'agit d'accéder à des fichiers sur le serveur ...)

Ps : Pas de soucis, c'est lundi matin, j'ai du mal à émerger et pas l'envie de replonger dans mon code ... :aie:
27/05/2013, 11h03
Pol63

le stacktrace c'est bien, mais ex.message nous aiderait plus
et vu que c'est une ioexception, en la castant tu auras un numéro d'erreur de l'os

Citation:

Envoyé par _Ez3kiel

Le fait de modifier la liste des .xls durant un for each sur cette dernière, n'altère-t-il pas le traitement ?

déplacer des fichiers sur le disque dur de modifie pas une collection dans un programme ^^
27/05/2013, 11h23
_Ez3kiel

Ha ... Je pensais vu que c'était une collection d'énumérator de fichiers d'un Path défini, qu'en déplaçant un des fichiers de ce même Path vers un autre, l'énumérator de la liste (ou la liste) s'en trouverait altéré... Mais je ne fais que des suppositions alors je ne m'avance pas plus :oops:

Et si j'ai bien lu, l'ex.message est Le chemin réseau n'a pas été trouvé
27/05/2013, 11h29
Sankasssss

Salut Pol63,

Citation:

Envoyé par Pol63

le stacktrace c'est bien, mais ex.message nous aiderait plus

Oui j'avais oublié de le mettre dans le premier message mais j'ai rectifié l'erreur à la demande de _Ez3kiel dans le poste 5 :

Citation:

Message : Le chemin réseau n'a pas été trouvé.

StackTrace : at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler)
at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption)
at System.IO.DirectoryInfo.GetFiles(String searchPattern)
at SL0025VB.Main.main(String[] args)

Source : mscorlib

Citation:

Envoyé par Pol63

et vu que c'est une ioexception, en la castant tu auras un numéro d'erreur de l'os

J'avoue ne pas te suivre, comment je dois caster cette erreur?

Citation:

Envoyé par Pol63

Citation:

Envoyé par _Ez3kiel

Le fait de modifier la liste des .xls durant un for each sur cette dernière, n'altère-t-il pas le traitement ?

déplacer des fichiers sur le disque dur de modifie pas une collection dans un programme ^^

En effet, on ne modifie nullement la collection en elle même donc pas de soucis sur ce point. De plus, il plante avant avoir déplacé le moindre fichier, avant même d'avoir commencé à énuméré la collection.

Citation:

Envoyé par _Ez3kiel

Sinon, est-ce que l'appli a été testé sur d'autres posts ? (Le terme aléatoire me rappelle que mon poste bien que je sois dans le même groupe IIS que mes collègues me fait quelques réprimandes de sécurité quand il s'agit d'accéder à des fichiers sur le serveur ...)

Oui et mon collègue n'avait jamais eu de problème lors des tests, c'est uniquement sur le serveur qu'elle pose problème, qu'elle soit lancé par une tâche planifiée ou manuellement sur le serveur via la session administrateur ne change rien au problème.

Nous avons rajouté une ligne pour écrire dans le log afin de vérifier que le serveur voit bien le dossier à énumérer :

Code:

Trace.WriteLine("Vérification si dossier : '" & savePath & "' visible : " & Directory.Exists(savePath).ToString)

mais bien sûr il ne plante plus lors de nos tests, il nous faudra attendre le prochain plantage pour vérifier le log. Que je n'aime pas les erreurs aléatoires :evilred:
27/05/2013, 11h30
Pol63

Citation:

Envoyé par _Ez3kiel

Ha ... Je pensais vu que c'était une collection d'énumérator de fichiers d'un Path défini, qu'en déplaçant un des fichiers de ce même Path vers un autre, l'énumérator de la liste (ou la liste) s'en trouverait altéré...

techniquement ca serait possible, mais je ne pense pas que c'est le cas, ca serait trop gourmand, surtout sur du réseau
ca serait donc logiquement un snapshot au moment de l'appel, fournit par l'os

Citation:

Envoyé par _Ez3kiel

Et si j'ai bien lu, l'ex.message est Le chemin réseau n'a pas été trouvé

ah oui je l'avais pas vu au milieu

après un démarrage de windows et accès depuis windows au dossier, y a t il une demande d'authentification ?
si non ca doit être une non réponse de l'os d'en face ... le réseau d'une manière générale est quelque chose qu'il faut traiter avec possibilité d'erreur
27/05/2013, 11h34
Pol63
Citation:

Envoyé par Sankasssss

J'avoue ne pas te suivre, comment je dois caster cette erreur?

quand on écrit catch ex as exception, on intercepte tout
la classe ioexception est dérivée de la classe exception avec des propriétés en plus, dont le numéro d'erreur

il existe une méthode pour intercepter "en select case" et typé
Code:

1 2 3 4 5 catch ex as ioexception ' code catch ex as exception ' code
il y a plein de types d'exception dans le framework, on peut même en créer d'autres
quand on marque plusieurs fois catch avec des types différents, ils sont testés tel un select case

sinon faire if typeof ex is ioexception then directcast(ex,ioexception)...
27/05/2013, 11h40
Sankasssss

Citation:

Envoyé par Pol63

après un démarrage de windows et accès depuis windows au dossier, y a t il une demande d'authentification ?

Non, j'accède sans soucis au dossier via l'explorateur du PC exécutant l'application, même avant de lancer l'application.

Citation:

Envoyé par Pol63

si non ca doit être une non réponse de l'os d'en face ... le réseau d'une manière générale est quelque chose qu'il faut traiter avec possibilité d'erreur

Yep, bien d'accord, mais hormis un Directory.Exists que peut-on faire? De plus, même en la traitant avec possibilité d'erreur, cela ne nous arrangera pas qu'il ne s’exécute pas parce qu'il y a une sois disant erreur alors que le serveur est dispo.
Y aurait-il une solution pour faire réagir l'autre serveur avant de faire ces instructions? Un ping?
27/05/2013, 11h42
Sankasssss
Citation:
Envoyé par Pol63

quand on écrit catch ex as exception, on intercepte tout
la classe ioexception est dérivée de la classe exception avec des propriétés en plus, dont le numéro d'erreur

il existe une méthode pour intercepter "en select case" et typé

Code:

1 2 3 4 5 catch ex as ioexception ' code catch ex as exception ' code

il y a plein de types d'exception dans le framework, on peut même en créer d'autres
quand on marque plusieurs fois catch avec des types différents, ils sont testés tel un select case

sinon faire if typeof ex is ioexception then directcast(ex,ioexception)...
Ah dans ce sens là, ok, ça on connait bien :P
27/05/2013, 12h01
_Ez3kiel

Aucun tiers n'a ouvert un des xls ? Posant ainsi un verrou ?
27/05/2013, 12h13
Pol63

Citation:

Envoyé par Sankasssss

Yep, bien d'accord, mais hormis un Directory.Exists que peut-on faire? De plus, même en la traitant avec possibilité d'erreur, cela ne nous arrangera pas qu'il ne s’exécute pas parce qu'il y a une sois disant erreur alors que le serveur est dispo.
Y aurait-il une solution pour faire réagir l'autre serveur avant de faire ces instructions? Un ping?

si le directory.exists fonctionne (enfin plante ^^) un while directory.exists (et un sleep 50)
après si même quand le exists passe le getfiles peut planter c'est le getfiles qu'il faudrait whiler

sinon travailler sur des dossiers réseaux ce n'est pas forcément une bonne pratique, si c'est pour un import/export de fichier, c'est alors un processus en tache de fond, auquel cas un while true + sleep convient parfaitement

Donc, après plantage, la ligne :

Code:

Trace.WriteLine("Vérification si dossier : '" & savePath & "' existe : " & Directory.Exists(savePath).ToString)

m'a bien donné :

Citation:

Vérification si dossier : '\\filesrv\data\RendezVousFichesB\' existe : False

Ce n'est donc pas un problème lié au Excel ou au contenu du dossier .

Je vais tester, comme conseillé, un :
Code:

1 2 3 4 5 6 7 8 9 10 11 Dim cpt As Integer = 1 While Not Directory.Exists(savePath) Trace.WriteLine(vbTab & "Vérification " & cpt & " a échoué") If cpt >= 50 Then Trace.WriteLine("Fin des " & cpt & " essais") Application.Exit() Exit Sub End If Threading.Thread.Sleep(500) cpt += 1 End While
Je vous tien au courant du résultat mais j'aimerais quand même bien savoir pourquoi le serveur d'application ne voit pas le serveur de fichier alors que se dernier est disponible. C'est inquiétant. 8O

27/05/2013, 13h33
Pol63

ca peut venir de plein de choses, de windows, d'un switch etc...
27/05/2013, 13h42
Sankasssss

Bien sur, mais c'est quand même bizarre qu'avec l’explorateur on a pas de soucis de connexion.
Les switch sont déjà éliminé vu qu'il s'agit de serveurs virtualisés sur la même machine, reste windows :roll:.
Bon, on va essayer de trouver à qui revient la faute même si ça va être dur...
27/05/2013, 14h09
_Ez3kiel

Citation:

Envoyé par MSDN

Les systèmes peuvent supprimer les connexions inactives après un délai d'attente spécifié (15 minutes par défaut) pour éviter de gaspiller des ressources de serveur sur des sessions non utilisées.

Lorsqu'il plante, tu étais actif sur le réseau les 15 minutes d'avant ? Ca pourrait expliquer le facteur "aléatoire" du bug ...

Ou si tu tentes avec l'ip dans le path plutôt le dns du serv ?
27/05/2013, 14h56
Sankasssss

Très bonne piste !!!
Tout dépend ce que l'on appel actif?
Je peux lancer le programme manuellement, donc je suis connecté en bureau à distance, c'est être actif ça?
Quand c'est via la tâche planifiée, je serais de ton avis que la connexions puisse être inactive mais quand je le lance manuellement je trouve ça plus spécial.
Mais je vais explorer cette piste, merci :)
27/05/2013, 15h10
Sankasssss

Bon après avoir testé l'idée de Pol63 ça passe au bout de 21 essais espacé de 500mS, donc après 10,5 secondes :

Citation:

Vérification si dossier : '\\filesrv\data\RendezVousFichesB\' existe

Vérification 1 a échoué
Vérification 2 a échoué
Vérification 3 a échoué
Vérification 4 a échoué
Vérification 5 a échoué
Vérification 6 a échoué
Vérification 7 a échoué
Vérification 8 a échoué
Vérification 9 a échoué
Vérification 10 a échoué
Vérification 11 a échoué
Vérification 12 a échoué
Vérification 13 a échoué
Vérification 14 a échoué
Vérification 15 a échoué
Vérification 16 a échoué
Vérification 17 a échoué
Vérification 18 a échoué
Vérification 19 a échoué
Vérification 20 a échoué
Vérification 21 a échoué
Ca passe

C'est vraiment pas top comme système mais ça passe.
Je vais regarder du coté de l'inactivité des connexions pour voir s'il y a moyen de faire des exceptions pour certaines connexions comme les différents serveurs fixe.

Merci encore à vous deux pour l'aide :ccool:
27/05/2013, 15h30
_Ez3kiel

Si j'ai bien compris, c'est un client qui lance le programme en tâche planifié, ce même programme qui va "faire son affaire avec ses xls" dans filesrv ?

Si oui, et si à ce que j'ai compris tu peux le lancer en tâche planifiée, sur le client qui lance l'appli, tente d'ouvrir un explorer qui pointe \\filesrv\data\RendezVousFichesB\ , on sera sûr que la connexion sera active, et illico après lance la tâche planifiée, si l'hypothèse est vrai, on ne devrait pas planter.
Ensuite, ferme tous les explorers ou quoi que ce soit qui pointe sur filesrv, va prendre un café, papote, etc ^^, attend 20/25mn, reviens et lance direct la tâche sans rouvrir d'explorer ou quoi que ce soit, on sera fixé si la connexion n'a pas été provisoirement coupé le temps d'une demande du client vers le réseau ...

Et si ce n'est pas ça, j'ai bien peur d'être à court d'idées ... :aie:

Bon courage pour la suite et n'hésite pas à poster la solution si tu trouves, ça pourrait être très instructif. ;)
27/05/2013, 15h38
Sankasssss

Bonne idée pour l'explorateur (même si ça reste une rustine) :ccool:

Je n'hésiterai pas à mettre la solution propre si je la trouve, c'est important pour la qualité du forum et par respect envers ceux qui aident...

Merci encore !!!
29/05/2013, 12h20
Sankasssss

Citation:

Envoyé par _Ez3kiel

Citation:

Envoyé par MSDN

Les systèmes peuvent supprimer les connexions inactives après un délai d'attente spécifié (15 minutes par défaut) pour éviter de gaspiller des ressources de serveur sur des sessions non utilisées.

J'avais trouvé cette page MSDN qui n'est pas exactement celle que _Ez3kiel citait mais qui me paraissait intéressante vu :

Citation:

Envoyé par MSDN

Ce comportement s'explique par le fait que les systèmes peuvent supprimer les connexions inactives après un délai d'attente spécifié (15 minutes par défaut) pour éviter de gaspiller des ressources de serveur sur des sessions non utilisées. La connexion peut être rétablie très rapidement, si nécessaire.

J'ai donc essayé la résolution proposée :

Citation:

Pour désactiver la fonctionnalité de déconnexion automatique, ouvrez une invite de commandes, tapez la ligne suivante et appuyez sur Entrée :
net config server /autodisconnect:-1

Malheureusement cela ne change rien :(

On continue nos recherches (entre nos différents projets, ce qui risque de prendre du temps)