Discussion :

[petard14]

Bonjour à tous, j'ai un pb en c# (.NET 2.0) que je n'arrive pas à résoudre.
Si quelqu'un avait une idée pour m'aider, ce serait sympa :

une application cliente, que je ne peux donc pas modifier, ajoute et supprime des fichiers dans un répertoire donné. Je dois, de mon côté, détecter ces ajouts et suppressions de manière fiable SANS verrouiller les fichiers au cas où le client voudrait en supprimer un.

Sur le principe, pas de pb. J'ai utilisé FileSystemWatcher, cela marche très bien. Là, où ca coince, c'est que FileSystemWatcher avertit dès le début de la copie du fichier et que je peux avoir des fichiers de 10 ko comme de 500 Mo.

Comment être averti que le fichier est fini de copier ?

L'astuce que j'ai trouvé est : dès que j'ai l'événement fichier_crée, j'essaie dans un while d'ouvrir un flux FileStream sur ce fichier. Tant que j'ai une erreur, je boucle. Quand je peux ouvrir mon flux, c'est que le fichier est fini de copier. Je ferme le flux pour ne pas le verrouiller.

Code : quand recu événement fichier_crée :

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 bool finiCopie = false;
 while (!finiCopie)
 {
         try
          {
                    FileStream fs = new FileStream(nomCompletFichier, FileMode.Open);
                    fs.Close();
                    finiCopie = true;
                }
                catch (Exception e)
                {}
            }
 }
 
// Je sors de la boucle donc ici, je sais que le fichier est fini de copier.

D'après vous, n'y a t-il pas un risque :
- que je verrouille le fichier pendant le laps de temps que mon flux FileStream s'ouvre ?
- que mon fichier soit supprimé entre temps et boucle sans fin ? -> je pensais dans ce cas créer un tableau string[] present : quand l'événement fichier_crée arrive, j'ajoute le nom du fichier dans present[] et modifier mon while par while (!finiCopie && nom du fichier trouvé dans present[]).

Sinon, j'ai essayé FileInfo.length, les dll natives avec kernel32.dll, j'ai toujours la taille totale du fichier même quand la copie du fichier n'est qu'au début.

Avez-vous une idée, svp ?
Faut-il que je passe en c++ plutot avec de l'asm ?

Merci d'avance.

[NicolasJolet]

Salut petard14,

Je ne connais pas de composant dans le framework qui permette de faire cela.
Tu vas certainement devoir passer par les API natives de Windows.
Pour cela, nul besoin de passer en C++, et encore moins en ASM, à moins que les performances soient ton soucis principal. Il faut juste que tu saches qu'utiliser les API natives reste tout de même plus confortable en C++ vu qu'il n'y a pas 36 conversions à effectuer.
Mais c'est tout à fait faisable en C#.

Ce qui pourrait être utile dans ton cas est le Hooking d'une application. Ca te permet d'intercepter certains messages qui sont envoyés à un thread ne faisant pas partie de ton processus.
Maintenant je n'ai pas en tête que la copie de fichier soit gérée par des messages, donc j'ai peur de t'envoyer dans un cul-de-sac.

Enfin tu peux commencer tes investigations par ICI et LÀ.

Bien à toi,
Nicolas

[cinemania]

L'accès à des ressources comme les fichiers étant totalement séparé de tout ce qui est environnement "graphique"... et donc de l'UI et par voie de conséquence, de GID, tout ce qui est message système relatif à ces ressources n'est pas conduit par la file des messages windows utilisées dans les contrôle fenêtrés, et donc n'est pas traité par le thread d'affichage.

Les threads qui accèdent à un fichier de façon blocante et synchrone, sont endormis, en attendant que le fichier ou la partie voulue, soit disponible, ensuite le système les réveille.. Ils sont endormis dans la fonction système de lecture/écriture du fichier et réveillés à cet endroit, il n'y a donc pas de vraie file de message à proprement dit, sauf pour les accès asynchrones ou non blocants, et même là...
Cependant il est possible de "hook" l'état d'un fichier au niveau du système d'exploitation en dehors d'une application, pour savoir si il est en cours de lecture/écriture, fermeture... maintenant ne me demande plus les fonctions associés, ca fait trop longtemps que j'ai pas touché à l'API Win32 native pour m'en souvenir.

Une facon de s'en convaincre, si tu lis ton fichier dans le code d'un handler d'evenement graphique, et que l'accès àcette ressource est lent, tu va bloquer l'affichage et l'ihm ne va plus répondre. Si en revanche tu met la lecture dans un thread séparé, cela marche sans problème, car le thread séparé est endormis, et non pas le thread de l'ihm. Et d'ailleurs comment, le thread de l'ihm, pourrait t'il savoir quel thread gérait le fichier, si le message arrivait sur cette file ?
En plus, un service windows, même sans interactions avec la session, peut accèder aux fichiers non ? c'est bien la preuve que cela ne passe pas par la file de message windows, pour ceux qui n'auraient pas été convaincus.