Как сохранить ReadDirectoryChangesW в отсутствии изменений файла

Есть много сообщений в Интернете о функции ReadDirectoryChangesW API, где отсутствуют файлы, когда есть много активности файла. Большинство винит скорость, с которой вызывается цикл функции ReadDirectoryChangesW. Это неверное предположение. Лучшее объяснение, которое я видел, находится в следующем сообщении, комментарий в понедельник, 14 апреля 2008 г. 2:15:27 PM

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

Резюме состоит в том, что функция ReadDirectoryChangesW сообщает об изменениях файла, поскольку они оставляют очередь на запись в файл, а не по мере добавления. И если слишком много добавлено перед тем, как быть совершенным, вы потеряете уведомление о некоторых из них. Вы можете увидеть это с вашей реализацией, если вы просто напишете программу, чтобы быстро создать 1000+ файлов в каталоге. Просто подсчитайте количество уведомлений о событиях в файле, и вы увидите, что есть моменты, когда вы не получите их всех.

Вопрос в том, нашел ли кто-нибудь надежный метод использования функции ReadDirectoryChangesW без необходимости сбрасывать объем каждый раз? Это недопустимо, если пользователь не является администратором, а также может потребоваться некоторое время для завершения.

Ответ 1

Если API ненадежен, тогда обходной путь может быть вашим единственным вариантом. Это, конечно, связано с отслеживанием последних изменений и имен файлов. Что это не значит, что вам нужно опросить при поиске изменений, скорее, вы можете использовать FileSystemWatcher в качестве средства запуска проверки.С >

Итак, если вы отслеживаете последние 50-100 раз событие ReadDirectoryChangesW ~~/FSW~~, и вы видите, что оно вызывается быстро, вы можете обнаружить это и вызвать специальное условие для получения все файлы, которые были изменены (и установите флаг для предотвращения будущих фальшивых событий FSW) в течение нескольких секунд.

Так как некоторые люди путаются в комментариях к этому решению, я предлагаю вам следить за тем, как быстрые события поступают из ReadDirectoryChangesW, и когда они поступают слишком быстро, попробуйте применить обходное решение (обычно это ручная развертка каталог).

Ответ 2

Мы никогда не видели, чтобы ReadDirectoryChangesW был на 100% надежным. Но лучший способ справиться с этим - отделить "отчетность" от "обработки".

У моей реализации есть поток, у которого есть только одно задание, для повторной очереди всех событий. Затем второй поток обрабатывает мою промежуточную очередь. В основном вы хотите как можно меньше мешать отчетности о событиях.

В условиях высоких CPU вы также можете препятствовать отчетности о событиях наблюдателя.

Ответ 3

Я встретил ту же проблему. Но я не нашел решения, гарантирующего получение всех событий. В нескольких тестах я мог знать, что функция ReadDirectoryChangesW должна быть вызвана как можно быстрее после возврата функции GetQueuedCompletionStatus. Я думаю, если скорость обработки файловой системы будет намного быстрее, чем скорость обработки моего приложения, приложение может потерять некоторые события.

В любом случае, я отделил логику синтаксиса от логики мониторинга и поместил логику синтаксического анализа в поток.