.net - Sådan holder du ReadDirectoryChangesW fra manglende filændringer

Indlæg af Hanne Mølgaard Plasc

Problem



Der er mange indlæg på internettet om ReadDirectoryChangesW API funktionen mangler filer, når der er meget filaktivitet. De fleste bebrejder den hastighed, hvormed ReadDirectoryChangesW-funktionsløkken kaldes. Dette er en forkert antagelse. Den bedste forklaring jeg har set er i følgende indlæg, kommentaren mandag den 14. april 2008 kl. 15:15:27


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


Resuméet er, at ReadDirectoryChangesW-funktionsrapporterne ændrer filerne, da de forlader fil-skrive-bag køen, ikke som de tilføjes. Og hvis der bliver tilføjet for mange, før de bliver begået, mister du varsel på nogle af dem. Du kan se dette med din implementering, hvis du bare skriver et program til at generere en 1000 + filer i en mappe, der er rigtig hurtig. Tæl kun hvor mange filhændelser du får, og du vil se, at der er tidspunkter, hvor du ikke vil modtage dem alle.


Spørgsmålet er, har nogen fundet en pålidelig metode til at bruge ReadDirectoryChangesW-funktionen uden at skulle spole lydstyrken hver gang? Dette er ikke tilladt, hvis brugeren ikke er administrator, og det kan også tage lidt tid at fuldføre.

Bedste reference


Hvis API'en er upålidelig, så kan en løsning være din eneste mulighed. Det indebærer selvfølgelig sandsynligvis at holde styr på sidstmodificerede og filnavne. Hvad dette ikke betyder, er at du skal undersøge, når du leder efter ændringer, men du kan bruge FileSystemWatcher som et middel til at udløse kontrol.


Så hvis du holder øje med de sidste 50-100 gange, skete ReadDirectoryChangesW /FSW hændelsen, og du ser, at den bliver kaldt hurtigt, du kan registrere dette og udløse den specielle betingelse for at få alle filerne som er blevet ændret (og sat et flag for at forhindre fremtidige falske FSW-hændelser midlertidigt) om få sekunder.


Da nogle mennesker er forvirrede i kommentarerne til denne løsning, foreslår jeg, at du skal overvåge, hvordan hurtige begivenheder kommer fra ReadDirectoryChangesW, og når de ankommer for hurtigt, så prøv at forsøge at finde en løsning (normalt manuelt fejning af en mappe).

Andre referencer 1


Vi har aldrig set ReadDirectoryChangesW for at være 100\% pålidelige. Men den bedste måde at håndtere det er at adskille 'rapportering' fra 'håndtering'.


Min implementering har en tråd, der kun har ét job, for at genkøbe alle begivenheder. Så en anden tråd til at behandle min mellemkø. Du vil i princippet forhindre rapportering af begivenheder så lidt som muligt.


Under høj CPU-situationer kan du også forhindre rapportering af watcher events.

Andre referencer 2


Jeg mødte det samme problem. Men jeg fandt ikke en løsning, der garanterer at få alle begivenheder. I flere tests kunne jeg vide, at ReadDirectoryChangesW-funktionen skal kaldes igen så hurtigt som muligt efter GetQueuedCompletionStatus-funktionen returneret. Jeg gætter på, om en proceshastighed for filsystemet er meget hurtigere end min ansøgningshastighed, kan programmet muligvis miste nogle hændelser.


Anyway, jeg adskilt en parsing logik fra en overvågning logik og placeret en parsing logik på en tråd.