FileSystemWatcher и окна 7
Я пишу инструмент, который контролирует сетевой каталог и убегает машины Windows Server 2008, событие OnChanged для FileSystemWatcher запускается правильно из файлов, помещенных в сетевой диск любым компьютером, который не использует Windows 7, по некоторым причинам если сумма скопированных файлов является больше чем 19 на окна 7 компьютеров (сразу) затем, никакие события не запущены, хотя это работает, если файлы сделаны индивидуально. Существует ли обходное решение для этого или - что, как ядро Windows 7 ведет себя с событиями FSW?
Просто для уточнения это работает на тысячи файлов при копировании с машины XP. (Программное обеспечение находится все еще на машине сервера 2008).
4 ответа
Из MSDN :
Операционная система Windows уведомляет ваш компонент об изменениях файлов в буфере, созданном FileSystemWatcher. Если за короткое время произойдет много изменений, буфер может переполниться. Это приводит к тому, что компонент теряет отслеживание изменений в каталоге и будет предоставлять только общее уведомление. Увеличение размера буфера с помощью свойства InternalBufferSize является дорогостоящим, так как оно происходит из невыгружаемой памяти, которую нельзя выгружать на диск, поэтому сохраняйте размер буфера как можно меньше, но достаточно большим, чтобы не пропустить ни одно изменение файла. Мероприятия. Чтобы избежать переполнения буфера, используйте свойства NotifyFilter и IncludeSubdirectories , чтобы можно было отфильтровать нежелательные уведомления об изменениях.
Если увеличения размера буфера недостаточно и вы не можете контролировать, сколько файлов запускают события одновременно, вам придется добавить дополнительный опрос.
См. Также этот связанный вопрос:
Обновление:
Может возникнуть соблазн просто увеличить размер буфера, но это следует делать осторожно. Фактически, когда дело доходит до доступа к сети, существует ограничение в 64 КБ. Класс FileSystemWatcher использует функцию Windows API ReadDirectoryChangesW ниже, которая имеет следующий предел:
ReadDirectoryChangesW завершается ошибкой с ERROR_INVALID_PARAMETER, когда длина буфера превышает 64 КБ и приложение отслеживает каталог по сети.Это связано с ограничением размера пакета в базовых протоколах обмена файлами.
Если вы хотите получить более полное представление о стоимости изменения размера буфера, вам следует взглянуть на сообщение Уолтера Ванга из Microsoft здесь:
FileSystemWatcher через сеть (полный текст цитируется ниже)
Мне очень жаль, что документация FileSystemWatcher.InternalBufferSize не очень четко заявил о размер буфера при мониторинге сети дорожка. Рекомендуется не более 64К при мониторинге сетевого пути.
FileSystemWatcher - это в основном .Net оболочка для Win32 ReadDirectoryChangesW API. Использовать ReadDirectoryChangesW, вы создаете и укажите буфер, который ОС будет внесите изменения. Тем не мение, то, что не упоминается в Документация ReadDirectoryChangesW (но намекают в FileSystemWatcher docs) заключается в том, что файловая система создает внутреннее ядро буфер для хранения информации об изменениях временно, пока не появится возможность обновить пользовательский буфер. Размер создаваемый буфер ядра того же размера, который указан в ReadDirectoryChangesW и создается в невыгружаемой памяти пула. Каждый раз FileSystemWatcher / ReadDirectoryChangesW создан / вызывается, новый буфер ядра также созданный.
Пулы памяти ядра (выгружаемые и не выгружаемые) откладываются в системе адресное пространство для драйверов устройств и другие используемые компоненты ядра. Они растут и сжимаются динамически по мере того, как необходимый. Текущий размер бассейны можно легко увидеть, перейдя в Вкладка "Производительность" Задачи Управляющий делами.Бассейны будут расти динамически, пока они не достигнут максимума значение, которое рассчитывается во время загрузки и зависит от доступной системы ресурсы (в основном RAM). Вы не хотите достичь этого максимального значения, иначе различные системные службы и драйверы начнет терпеть неудачу. Однако это рассчитать максимальное значение непросто доступный. Чтобы определить максимальную размеры пула, нужно использовать ядро отладчик. Если вы заинтересованы в дополнительная информация о системе пулы памяти, рекомендую вам посмотрите главу 7 в книге MSPress Внутри Windows 2000 Соломона и Руссинович.
Имея это в виду, нет рекомендация по какому размеру буферов ты можешь использовать. Текущий и максимальный размер системных пулов будет варьироваться от клиента к клиенту. Однако вам, вероятно, не стоит идти более 64 КБ для каждого FileSystemWatcher / Буфер ReadDirectoryChangesW. Этот проистекает из того факта, что существует Ограничение 64k с доступом к сети как задокументировано в ReadDirectoryChangesW. Но в конце концов у вас будет протестировать приложение на множестве ожидаемых целевых систем, чтобы вы можете настроить свой буфер.
С .Net связаны накладные расходы приложений, и я полагаю, что Программа Win32 ReadDirectoryChangesW мог бы достичь большего производительность при том же размере буфера. Однако с очень быстрыми и многочисленными изменения файла, переполнение буфера будет неизбежно, и разработчик собирается иметь дело с ситуацией, когда происходит перерасход, например, вручную перечисление каталога для обнаружения перемены.
В заключение, FileSystemWatcher и ReadDirectoryChangesW - это легкое обнаружение изменения файла механизм, который будет иметь ограничения. Журналы изменений другой механизм, который мы бы рассмотреть вариант среднего веса,но по-прежнему будут иметь ограничения:
http://msdn.microsoft.com/en-us/library/aa363798%28VS.85%29.aspx
Тяжелые решения будут написать специальный фильтр файловой системы драйвер, который находится в файловой системе стек и контролирует файловую систему изменения. Конечно, это будет самый комплексный подход. Большинство вирусов сканеры, программное обеспечение для резервного копирования и файловые утилиты системного мониторинга, такие как filemon (www.sysinternals.com) реализовать драйвер фильтра.
Надеюсь, приведенное выше объяснение поможет вам понять основную причину проблемы вы переживаете. Пожалуйста ответьте на дайте нам знать, нужен ли вам дальнейшая информация. Спасибо.
В большинстве случаев, когда возникает событие FileSystemWatcher, я игнорирую файлы, передаваемые объектом, потому что этот список может быть неполным.
Я просто просматриваю каталог, который отслеживает объект FileSystemWatcher, и выполняю сканирование вручную, чтобы найти файлы, которые могут отсутствовать в буфере FileSystemWatcher. Это не очень элегантно, но гарантирует, что вы не пропустите файл.
После многих попыток использования FileSystemWatcher я отказался от него. Он не вызывает события правильно, в неправильное время, неправильного типа. Честно говоря, я думаю, что это один из худших классов в .net framework. В итоге я всегда писал свой собственный класс, который принимает System.Timer и по истечении x миллисекунд проверяет каталоги и файлы вручную. Да, это требует больше работы и да, это может быть небольшим неудобством, но как только вы его написали, вы можете использовать его везде, где захотите. Я бы хотел, чтобы FileSystemWatcher работал так, как рекламируется, но я никогда не находил его таким.
Это действительно ненадежный класс, когда файлы превышают определенный порог, у меня было 7 событий при первоначальном копировании, а затем, когда диалог передачи файла завершен, я получаю еще 7 событий, эта проблема возникает во всех ОС, поддерживающих FSW. Хотя Windows 7 (еще не пробовал vista) все еще принимает файлы только по одному или по 19 за раз, в то время как если я сбрасываю файлы с машины XP на сетевой диск, я могу читать тысячи файлов одновременно без каких-либо проблем. Возможно, это просто изменение в ReadDirectoryChangesW с XP на 7. После 19 файлов я не смог добиться срабатывания ЛЮБЫХ событий, так что, думаю, это пока станет "особенностью" моего инструмента. Если у кого-нибудь есть другая информация, не стесняйтесь ее предоставить.