FileSystemWatcher против опроса, чтобы наблюдать за изменениями файла

Лично, я использовал FileSystemWatcher в производственной системе, и она хорошо работала. За прошлые 6 месяцев это не имело единственного выполнения отклонения 24x7. Это контролирует единственную локальную папку (который совместно используется). Мы имеем относительно небольшое количество операций файла, которые оно должно обработать (10 событий, запущенных в день). Это не что-то, о чем я должен был когда-либо волноваться. Я использовал бы его снова, если бы я должен был переделать решение.

Эти FileSystemWatcher может также пропустить изменения в течение напряженного времени, если количество изменений с очередями переполняет обеспеченного буфера. Это не ограничение класса.NET по сути, но базовой инфраструктуры Win32. По нашему опыту, лучший способ минимизировать эту проблему состоит в том, чтобы исключить из очереди уведомления как можно быстрее и соглашение с ними на другом потоке.

, Как упомянуто @ChillTemp выше, наблюдатель не может работать над долями не-Windows. Например, это не будет работать вообще над смонтированными дисками Novell.

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

Также обратите внимание, что наблюдатель файловой системы не надежен на долях файла. Особенно, если доля файла размещается на сервере не-Windows. FSW не должен использоваться ни для чего критического. Или должен использоваться со случайным опросом, чтобы проверить, что он ничего не пропустил.

У меня были некоторые большие проблемы с FSW на сетевых дисках: Удаление файла всегда бросало ошибочное событие, никогда удаленное событие. Я не нашел решение, таким образом, я теперь избегаю опрос использования и FSW.

события Creation, с другой стороны, хорошо работали, поэтому если только необходимо наблюдать за созданием файла, можно пойти для FSW.

кроме того, у меня не было проблем вообще на локальных папках, неважно, если совместно использовано или нет.

Я столкнулся с проблемой с помощью FileSystemWatcher на сетевых ресурсах. Если Вы находитесь в чистой среде Windows, это не могла бы быть проблема, но я наблюдал долю NFS и так как NFS является не сохраняющим состояние, никогда не было уведомления, когда файл я смотрел измененный.

Я в настоящее время использую FileSystemWatcher на XML-файле, обновляемом в среднем каждые 100 миллисекунд.

я нашел, что пока эти FileSystemWatcher правильно настроен, у Вас никогда не должно быть проблем с локальный файлы.

у меня нет опыта в удаленном наблюдении файла и долях не-Windows.

я полагал бы, что опрос файла избыточен и не стоит издержек, если Вы по сути не не доверяете FileSystemWatcher или непосредственно испытали ограничения, все остальные здесь перечислили (доли не-Windows и удаленное наблюдение файла).

Я пошел бы с опросом.

Сетевые проблемы заставляют FileSystemWatcher быть ненадежными (перегружая ошибочное событие).

Самая большая проблема, с которой я столкнулся, - это отсутствие файлов при заполнении буфера. Исправить как пирог - просто увеличьте буфер. Помните, что он содержит имена файлов и события, поэтому увеличьте его до ожидаемого количества файлов (методом проб и ошибок). Он действительно использует память, которая не может быть выгружена, поэтому может заставить другие процессы обращаться к страницам, если память становится мало.

Вот статья MSDN о буфере: FileSystemWatcher .. ::. InternalBufferSize Свойство

Согласно MSDN:

Увеличение размера буфера является дорогостоящим, поскольку оно происходит из невыгружаемой памяти, которую нельзя выгружать на диск, поэтому сохраняйте размер буфера как можно меньше. Чтобы избежать переполнения буфера, используйте свойства NotifyFilter и IncludeSubdirectories, чтобы отфильтровать нежелательные уведомления об изменениях.

Мы используем 16 МБ, так как единовременно ожидается большой пакет. Работает нормально и никогда не пропускает файл.

Мы также читаем все файлы перед тем, как начать обработку даже одного ... получить имена файлов в безопасном кэше (в нашем случае в таблице базы данных), а затем обработать их.

Для проблем с блокировкой файлов я вызываю процесс, который ждет разблокировки файла одну секунду, затем две, затем четыре и так далее. Мы никогда не опрашиваем.