Question sur les mécanines internes de FileSystemWatcher.

Bonjour, j'ai fait une classe qui remplace filesystemwatcher, ça m'a pris du temps mais j'ai de gros doutes à l'arrivée en fait, déjà je récupère l'id du fichier par "GetFileInformationByHandle" via la dll kernel32.dll

Mais j'ai plein de doutes déjà en passant d'un disque dur à l'autre est ce que les ID seront les mêmes... Pour le moment ça ne me rapporte pas d'erreur, ça dresse la liste régulièrement des fichiers, et s'il y a changement ça lève des events après diverses comparaisons entre les deux listes. Basique quoi.. Mais j'ai ce doute sur les ids, en passant d'un hdd à l'autre.

Et bref du coup j'ai réussi à trouver le code source de filesystemwatcher, mais pour le moment j'ai du mal à comprendre comment et ou il récupère les informations en fait... apparemment il y a un système d'eventnotifier, mais je ne trouve pas ou.... Je me dis que windows en lui même doit émettre un signal ou bien qu'il doit archiver des informations dans un log, etc etc...Mais je ne vois pas pour le moment.

Merci.

je ne pense qu'il soit judicieux de le redévelopper, surtout que tu dois faire un balayage du disque dur, ce qui sera nettement moins performant.

certaines choses dans le framework ne sont pas codées en .net et utilisent des api (dll) de windows
le filesystemwatcher doit se cabler sur une api qui sert à ca, en effet windows gère tout le matériel donc quand quelqu'un modifie un fichier windows le sait par essence, donc il peut notifier par un genre d'event ceux qui veulent être tenus au courant, ce qui ne consomme rien en performance

à vérifier tout de même mais ca serait bête que ca ne fonctionne pas comme ca en interne ^^

Je me suis dit la même chose concernant les events. Après plusieurs choses me tirent soucis, mais bon quand j'ai redéveloppé, c'est là ou j'ai mis en place de récupérer l'id, avec le recul j'aurais pu le faire dès qu'un évent était déclenché pour voir la concordance. Mon algo gère en fait plusieurs répertoires à la fois, là ou le FSW gère un par un.

Sinon, ça ne scanne pas tout le hdd, je mets une liste de répertoires à surveiller donc ça ne s'occupe que de ces répertoires pour le moment j'ai juste un démarrage de 5s pour scanner la première passe sur 7000 fichiers, après chaque passe est de quelques ms, c'est le fait de récupérer l'id qui bouffe du temps. mais quand ça ne porte que sur une dizaine de fichiers c'est assez transparent ~6ms. Et lorsqu'il ne se passe rien ça n'est pas mesurable. Niveau mémoire je ne bouffe pas plus de 100mo. Après mon algo bosse en asynchrones sur chaque dossier... les tâches s'attendent pour gérer les fichiers qui ont bougé d'un répertoire surveillé à un autre, ce que ne gère pas en fait filesystemwatcher.

Dès le début en fait ça m'a chagriné car je venais de python sous ubuntu, et chaque event me ramenait un cookie avec un numéro unique, donc si j'avais un delete.. puis un create, et que les cookies correspondaient j'avais l'assurance que c'était le même fichier. Là avec FSW j'ai l'impression que si je supprime un fichier et qu'un autre porte le même nom (genre nouveau fichier.txt, un classique), il n'est pas capable de distinguer si c'était un fichier déplacé entre deux répertoires surveillés ou bien deux choses distinctes.

Je me dis qu'à la limite si je pouvais reproduire le même système que le fsw en récupérant dès la suppression l'id du fichier sur une partition nfs, là en revanche il y aurait une assez bonne certitude de correspondance et j'aurais une solution ultime, totalement instantanée. Mon logiciel gère en fait le calcul de somme (md5,sha) etc, et il "suit" tout changement des fichiers surveillés, si les fichiers sont les mêmes il reporte la somme sans recalculer à chaque coup, d'ou gain de temps. Donc c'est pas terrible terrible s'il détecte pas la correspondance mais c'est quand même un bon gros calcul selon la taille du fichier s'il a à recalculer (c'est géré par un autre process asynchrone indépendant de celui qui gère la surveillance).


----------------
J'ai peut être trouvé de quoi faire avec ça, faudra que je m'y penche, mais plus tard.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx