Comment empêcher les modifications de fichiers manquantes dans ReadDirectoryChangesW

Question

Il existe de nombreux articles sur Internet à propos des fichiers manquants de la fonction API ReadDirectoryChangesW lorsqu'il y a beaucoup d'activité de fichier. La plupart reprochent la vitesse à laquelle la boucle de la fonction ReadDirectoryChangesW est appelée. C'est une supposition incorrecte. La meilleure explication que je l'ai vu est dans le post suivant, le commentaire le lundi 14 Avril, 2008 14:15:27

http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/

Le résumé est que le fichier des rapports de fonction ReadDirectoryChangesW changements lorsqu'ils quittent la File-Write-derrière la file d'attente, pas comme ils sont ajoutés. Et si un trop grand nombre est ajouté avant d'être commis, vous perdez l'attention sur certains d'entre eux. Vous pouvez le voir avec votre implémentation, si vous écrivez simplement un programme pour générer rapidement plus de 1000 fichiers dans un répertoire. Il suffit de compter le nombre d'avis d'événements de fichiers que vous obtenez et vous verrez qu'il y a des moments où vous ne les recevrez pas tous.

La question est, quelqu'un a trouvé une méthode fiable pour utiliser la fonction ReadDirectoryChangesW sans avoir à vider le volume à chaque fois? Cela n'est pas autorisé si l'utilisateur n'est pas administrateur et peut également prendre un certain temps pour terminer.

Answer 1

Si l'API n'est pas fiable, une solution de contournement peut être votre seule option. Bien sûr, cela implique probablement le suivi des noms et noms de fichiers modifiés. Ce que cela ne signifie pas, c'est que vous avez besoin d'interroger lors de la recherche de modifications, vous pouvez plutôt utiliser le FileSystemWatcher comme moyen de déclencher la vérification.

Donc, si vous garder une trace des 50-100 dernières fois l'événement ReadDirectoryChangesW /FSW se produisait, et vous voyez qu'il est appelé rapidement, vous pouvez détecter et déclencher la condition spéciale pour obtenir tous les fichiers qui ont été changés (et définir un drapeau pour empêcher temporairement de futurs événements faux FSW) dans quelques secondes. Comme certaines personnes sont confuses dans les commentaires sur cette solution, je vous propose de surveiller la vitesse à laquelle les événements arrivent à partir de ReadDirectoryChangesW et lorsqu'ils arrivent trop vite, essayez de tenter une solution de contournement (généralement un balayage manuel de un répertoire).

Answer 2

J'ai rencontré le même problème. Mais, je n'ai pas trouvé de solution garantissant l'obtention de tous les événements. Dans plusieurs tests, je pourrais savoir que la fonction ReadDirectoryChangesW devrait être appelée à nouveau aussi vite que possible après que la fonction GetQueuedCompletionStatus soit retournée. Je suppose que si une vitesse de traitement du système de fichiers est très rapide que la vitesse de traitement de ma demande, l'application pourrait être en mesure de perdre certains événements.

Quoi qu'il en soit, j'ai séparé une logique d'analyse d'une logique de surveillance et placé une logique d'analyse sur un thread.

Answer 3

Nous n'avons jamais vu ReadDirectoryChangesW être fiable à 100%. Mais, la meilleure façon de le gérer est de séparer le "reporting" du "handling".

Mon implémentation a un thread qui n'a qu'un seul travail, pour remettre tous les événements en file d'attente. Ensuite, un deuxième thread pour traiter ma file d'attente intermédiaire. En gros, vous voulez empêcher le plus possible de rendre compte des événements. En cas de CPU élevée, vous pouvez également empêcher le signalement des événements d'observateur.