Информация об изменениях

Сообщение Re[2]: IRP_MJ_CREATE, минифильтр. Как отличить именно СОЗДАН от 04.01.2018 9:06

Изменено 04.01.2018 9:11 sergey77666

Re[2]: IRP_MJ_CREATE, минифильтр. Как отличить именно СОЗДАН
Здравствуйте, ononim, Вы писали:

S>>Вот такой код. Должно "лететь в лог" только создание файлов в обычном понимании.

S>>Не папок.
S>>И не открытие, а именно создание.
S>>PreFileOperationCallback (
O>Сразу — ошибка в дизайне. До исполнения операции никак нельзя знать будет файл создан или открыт существующий, т.к. таких операций может прилететь одновременно 100500 штук и какая именно из них в итоге файл создаст, а какие окажутся опоздунами — будет ясно только постфактум, после того как запросы пролетят через фс.
O>Так что ищите ответ в Post FileOperationCallback

Согласен, ошибка в дизайне этого API. Да и не то, что ошибка, а просто нет никакого дизайна, просто никто не позаботился, чтобы оно не было таким, какое оно и есть (каким его проще сделать), а было реально удобно им пользоваться.

Если нужен не столько даже мониторинг, сколько возможность запретить именно создание именно файла, то глубоко насрать, сколько там операций прилетит этому файлу. Все равно либо запрещать все, либо разрешать все.
И также глубоко, будет ли оно там реально создан или помешает скажем нехватка места на диске — важна сама попытка его создать. А попытку создать можно определять по наличию одного из флагов, способных создавать файл, ПЛЮС по отсутствию файла до вызова. Но вот как нормально проверить последнее, и не вызвать этим рекурсии (Create) — я пока не знаю.
В данном драйвере применю Post.
Re[2]: IRP_MJ_CREATE, минифильтр. Как отличить именно СОЗДАН
Здравствуйте, ononim, Вы писали:

S>>Вот такой код. Должно "лететь в лог" только создание файлов в обычном понимании.

S>>Не папок.
S>>И не открытие, а именно создание.
S>>PreFileOperationCallback (
O>Сразу — ошибка в дизайне. До исполнения операции никак нельзя знать будет файл создан или открыт существующий, т.к. таких операций может прилететь одновременно 100500 штук и какая именно из них в итоге файл создаст, а какие окажутся опоздунами — будет ясно только постфактум, после того как запросы пролетят через фс.
O>Так что ищите ответ в Post FileOperationCallback

Согласен, ошибка в дизайне этого API. Да и не то, что ошибка, а просто нет никакого дизайна, просто никто не позаботился, чтобы оно не было таким, какое оно и есть (каким его проще сделать), а было реально удобно им пользоваться.

Если нужен не столько даже мониторинг, сколько возможность запретить именно создание именно файла, то глубоко насрать, сколько там операций прилетит этому файлу. Все равно либо запрещать все, либо разрешать все.
И также глубоко, будет ли оно там реально создан или помешает скажем нехватка места на диске — важна сама попытка его создать. А попытку создать можно определять по наличию одного из флагов, способных создавать файл, ПЛЮС по отсутствию файла до вызова. Но вот как нормально проверить последнее, и не вызвать этим рекурсии (Create) — я пока не знаю.

В данном драйвере применю Post.
Этот драйвер — только мониторит.
Зачем он вообще нужен, я не знаю. Заказчик очень скрытный тип.
Но, скажем, если это такой тул для детекта вредоногосного ПО, то вроде очевидно, что не стоило бы пропускать попытки сотворить недозволенное (и тем самым оставлять зловред без внимания!) лишь из-за того, что они по какой-то причине провалились... А значит, Pre лучше...