ReadDirectoryChangesW: как обнаружить переполнение буфера при асинхронном использовании?

Question

Я использую ReadDirectoryChangesW (Windows API) в асинхронном режиме в сочетании с GetQueuedCompletionStatus .Как я могу обнаружить возможное переполнение буфера, чтобы понять, что по крайней мере одно событие изменения файловой системы было потеряно?

Answer 1

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

1. Произошло некоторое событие.
2. Асинхронная операция, начатая ReadDirectoryChangesWзавершается успешно.Ваш буфер заполнен, ваш дескриптор события установлен или IOCP запущен.
3. Происходят дополнительные события, которые хранятся в буфере уровня ОС.
4. Происходит больше дополнительных событий, которые переполняютБуфер уровня ОС.Это не меняет статус перекрытой операции, которая уже была выполнена успешно на шаге 2.
5. Вы ожидаете обработчик события или обрабатываете IOCP и обнаруживаете завершенный вызов OVERLAPPED.
6. Вы снова вызываете ReadDirectoryChangesW , чтобы начать асинхронную операцию перекрытия, проверяющую любые события, произошедшие после шага 2. Этот вызов завершается неудачно синхронно, с GetLastError() == ERROR_NOTIFY_ENUM_DIR или успешно dwBytesTransferred == 0, поскольку в документации сказано, что это также означает повторное перечисление каталога

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

Answer 2

Возможно, вы не сможете выполнить обнаружение таким образом, но здесь - это отличное руководство, которое может помочь.

Вы также можете проверить ответ на этот другой вопрос.

Answer 3

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

Предложение: следите за изменениями синхронно, но в выделенном потоке, и следите за ERROR_NOTIFY_ENUM_DIR.