Jak zachować ReadDirectoryChangedW z brakujących zmian w plikach

Question

Istnieje wiele postów w Internecie na temat funkcji ReadDirectoryChangesW funkcji brakujących plików, gdy istnieje wiele działań plików. Najbardziej obwinia szybkość, z jaką wywoływana jest pętla funkcji ReadDirectoryChangesW. To błędne założenie. Najlepszym wyjaśnieniem Widziałem to w następnym poście, komentarz w poniedziałek, 14 kwietnia 2008 14:15:27

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

Podsumowanie to, że raporty funkcyjne ReadDirectoryChangesW zmian plików jak oni opuścić kolejka write-behind za, a nie po dodaniu. A jeśli zbyt wiele zostanie dodanych przed popełnieniem, tracisz uwagę na niektórych z nich. Możesz to zobaczyć ze swoją implementacją, jeśli po prostu napisz program, który wygeneruje ponad 1000 plików w katalogu naprawdę szybko. Po prostu policz, ile dostaniesz powiadomień o zdarzeniach, a zobaczysz, że są chwile, kiedy nie otrzymasz ich wszystkich.

Pytanie brzmi, czy ktoś znalazł niezawodną metodę używania funkcji ReadDirectoryChangesW bez konieczności przepłukiwania woluminu za każdym razem? Jest to niedozwolone, jeśli użytkownik nie jest administratorem i może również potrzebować trochę czasu.

Answer 1

Jeśli interfejs API nie jest wiarygodny, obejście może być jedyną opcją. To oczywiście wiąże się ze śledzeniem ostatniej modyfikacji i nazw plików. Nie oznacza to, że trzeba sondować, gdy szuka się zmian, ale można użyć FileSystemWatcher jako sposobu wyzwalania sprawdzania.

Więc jeśli śledzić ostatnie 50-100 razy ReadDirectoryChangesW /FSW zdarzenie miało miejsce, a zobaczysz, że nazywa się gwałtownie, można wykryć i wywołać stan szczególny, aby wszystkie pliki które zostały zmienione (i ustawiono tymczasowo flagę, aby zapobiec przyszłym fałszywym zdarzeniom FSW) w ciągu kilku sekund.

Ponieważ niektórzy ludzie są zdezorientowani w komentarzach dotyczących tego rozwiązania, proponuję, aby monitorować, jak szybko nadchodzą zdarzenia z ReadDirectoryChangesW, a gdy docierają one zbyt szybko, spróbuj podjąć próbę obejścia (zwykle ręczne przeciągnięcie katalog).

Answer 2

Spotkałem ten sam problem. Ale nie znalazłem rozwiązania gwarantującego uzyskanie wszystkich zdarzeń. W kilku testach mogłem wiedzieć, że funkcja ReadDirectoryChangesW powinna być wywoływana ponownie tak szybko, jak to możliwe po zwróceniu funkcji GetQueuedCompletionStatus. Zgaduję, że jeśli szybkość przetwarzania systemu plików jest większa niż szybkość przetwarzania mojej aplikacji, aplikacja może utracić pewne zdarzenia.

W każdym razie oddzieliłem logikę parsowania od logiki monitorowania i umieściłem logikę parsowania w wątku.

Answer 3

Nigdy nie widzieliśmy ReadDirectoryChangesW na 100% niezawodne. Najlepszym sposobem radzenia sobie z tym jest oddzielne "raportowanie" od "obsługi".

Moja implementacja ma wątek, który ma tylko jedno zadanie, aby ponownie umieścić w kolejce wszystkie zdarzenia. Następnie drugi wątek do przetworzenia mojej pośredniej kolejki. Zasadniczo, chcesz ograniczyć zgłaszanie zdarzeń w jak najmniejszym stopniu.

W sytuacjach o dużym obciążeniu procesora można również utrudniać zgłaszanie zdarzeń obserwatora.