Как уберечь ReadDirectoryChangesW от пропущенных изменений файла
В Интернете есть много сообщений о том, что функция API ReadDirectoryChangesW пропускает файлы при большой активности файлов. Большинство винят скорость, с которой вызывается цикл функции ReadDirectoryChangesW. Это неверное предположение. Лучшее объяснение, которое я видел, находится в следующем сообщении, комментарии от понедельника, 14 апреля 2008 г., 14:15:27.
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/
Подводя итог, можно сказать, что функция ReadDirectoryChangesW сообщает об изменениях файлов по мере их выхода из очереди с отложенной записью файлов, а не по мере их добавления. И если слишком много добавлено до того, как они будут зафиксированы, вы потеряете внимание к некоторым из них. Вы можете увидеть это в своей реализации, если просто напишете программу для очень быстрой генерации более 1000 файлов в каталоге. Просто посчитайте, сколько уведомлений о файловых событиях вы получите, и вы увидите, что бывают случаи, когда вы не получите их все.
Вопрос в том, нашел ли кто-нибудь надежный способ использовать функцию ReadDirectoryChangesW без необходимости каждый раз сбрасывать том? Это недопустимо, если пользователь не является администратором, и для завершения может потребоваться некоторое время.
Ответы 3
Если API ненадежен, то обходной путь может быть вашим единственным вариантом. Это, конечно, вероятно, связано с отслеживанием lastmodified и имен файлов. Это не означает, что вам нужно проводить опрос при поиске изменений, скорее, вы можете использовать FileSystemWatcher как средство для запуска проверки.
Поэтому, если вы отслеживаете последние 50-100 раз, когда произошло событие ReadDirectoryChangesW/ FSW, и видите, что оно вызывается быстро, вы можете обнаружить это и запустить специальное условие, чтобы получить все файлы, которые были изменены (и установить флаг для временного предотвращения будущих ложных событий FSW) за несколько секунд.
Поскольку некоторые люди запутались в комментариях к этому решению, я предлагаю вам отслеживать, насколько быстро события прибывают из ReadDirectoryChangesW, и когда они прибывают слишком быстро, попробуйте попытаться обходной путь (обычно ручное сканирование каталога).
Класс FileSystemWatcher - это .NET способ обернуть ReadDirectoryChangesW, так что нет, это не помогает.
Мой ответ был больше об обнаружении количества событий в течение периода времени, чтобы запустить обходной путь для ReadDirectoryChangesW.
И некоторые из этих событий также будут отброшены и никогда не появятся, как и при попытке использовать ReadDirectoryChangesW (). Нарядить его с FSW бесполезно.
Хорошо, замените все вхождения FileSystemWatcher на ReadDirectoryChangesW, и ответ по-прежнему будет ТО ЖЕ. Вам все равно нужно будет определять, когда файлы поступают быстро, и выполнять свою собственную очистку каталога.
Нет, это не так, потому что события включают «когда файлы прибывают», которые вы никогда не увидите. Другими словами, ответ на исходный вопрос - НЕТ. И нет абсолютно НИКАКОГО РЕШЕНИЯ, кроме использования другого механизма, такого как ведение журнала изменений или создание минифильтра файловой системы. Как можно использовать ReadDirectoryChangesW () опять таки, чтобы компенсировать недостаток собственного дизайна, как-то «обойти» его? Непонятно.
Я встретил ту же проблему. Но я не нашел решения, которое гарантировало бы получение всех событий. В нескольких тестах я мог знать, что функция ReadDirectoryChangesW должна вызываться снова как можно быстрее после возврата функции GetQueuedCompletionStatus. Я предполагаю, что если скорость обработки файловой системы намного выше, чем скорость обработки моего приложения, приложение может потерять некоторые события.
В любом случае, я отделил логику синтаксического анализа от логики мониторинга и поместил логику синтаксического анализа в поток.
Я успешно решил проблему с помощью чего-то похожего. Поставьте события в очередь или запишите их в файл для последующей обработки. Запись их на диск была для меня ключевым моментом. Это может показаться медленным, но диски кэшируются, а накладные расходы меньше, чем у БД. Моя программа отражает около 1 ТБ в день изменений файлов - сотни тысяч файлов в день.
Мы никогда не видели, чтобы ReadDirectoryChangesW был на 100% надежным. Но лучший способ справиться с этим - отделить «отчетность» от «обработки».
В моей реализации есть поток, у которого есть только одно задание - повторно поставить все события в очередь. Затем второй поток для обработки моей промежуточной очереди. По сути, вы хотите как можно меньше препятствовать освещению событий.
В ситуациях с высокой загрузкой ЦП вы также можете препятствовать отправке отчетов о событиях-наблюдателях.
Поскольку у меня недостаточно репутации, чтобы комментировать выше, я скажу, что лучшее решение очень хорошее. Это дает вам "почти готово" в 99% случаев. Добавьте к нему еще одну вещь: периодическое полное повторное сканирование просматриваемых папок на предмет изменений.
Это будет работать примерно 99% времени. Что произойдет, если будет пропущен файл в другом каталоге (кроме того, в котором много изменений файла). Вы просканируете один каталог на предмет изменений, но пропустите изменение одного файла в другом.