Здравствуйте, axxie, Вы писали:

A>Здравствуйте, x64, Вы писали:

AA>>>Нисколько не умаляя достоинств минифильтров... чем в данном случае FltCreateFile лучше, чем IoCreateFileSpecifyDeviceObjectHint?

x64>>Перечитай всю ветку ещё раз более внимательно. Для IoCreateFileSpecifyDeviceObjectHint() нужно иметь под рукой указатель на целевой девайс, в то время как для FltCreateFile() достаточно передать указатель на экземпляр своего минифильтра и запрос автоматически пойдёт к тому девайсу, который ниже по стеку (см. параметр Instance у этой функции). Т.е. с минифильтрами думать о рекурсиях в общем случае не приходится.

A>Автор спрашивал в своём первом сообщении о защите от рекурсии при открытии файла по имени. А получить экземпляр своего фильтра по имени — это не совсем простая задача. Нужно сначала получить объект тома с помощью вызова FltGetVolumeFromName, а потом из него получить экземпляр с помощью вызова FltEnumerateInstances. Причём FltGetVolumeFromName — это очень медленная функция, и она тоже требует путь к устройству \Device\Harddiskvolume1.
A>Проблем нет, только если вы точно знаете, что открываемый файл лежит на том же томе, что и файл, к которому пришёл запрос, например в Pre-Create колбек. В этом случае экземпляр фильтра приходит вам в параметрах.

A>Кстати, FltCreateFile внутри реализована именно через IoCreateFileSpecifyDeviceObjectHint.

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

А>проблема решения файла по имени для файла запрос на открытие которого приходит в irp create решена с помощью IoCreateFileSpecifyDeviceObjectHint, т.к. известен указатель на нижнее устройство.
А>осталась проблема с открытием файла по имени, когда это имя приходит от моего приложения через IOCTL запрос. получить имя нижнего устройства в этом случае не получается.
Как я понимаю, ты шлешь IOCTL на специальный CDO. Что если посылать его непосредственно на тот файл, путь к которому сейчас передается в IOCTL? Я имею в виду, открываем этот файл, а потом на его же хэндл шлем IOCTL. В этом случае запрос попадает сразу на нужный девайс-фильтр. Правда, сам файл должен существовать на момент вызова.

Здравствуйте, angry.andrew, Вы писали:

А>>проблема решения файла по имени для файла запрос на открытие которого приходит в irp create решена с помощью IoCreateFileSpecifyDeviceObjectHint, т.к. известен указатель на нижнее устройство.
А>>осталась проблема с открытием файла по имени, когда это имя приходит от моего приложения через IOCTL запрос. получить имя нижнего устройства в этом случае не получается.
AA>Как я понимаю, ты шлешь IOCTL на специальный CDO. Что если посылать его непосредственно на тот файл, путь к которому сейчас передается в IOCTL? Я имею в виду, открываем этот файл, а потом на его же хэндл шлем IOCTL. В этом случае запрос попадает сразу на нужный девайс-фильтр. Правда, сам файл должен существовать на момент вызова.

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

AA>>Как я понимаю, ты шлешь IOCTL на специальный CDO. Что если посылать его непосредственно на тот файл, путь к которому сейчас передается в IOCTL? Я имею в виду, открываем этот файл, а потом на его же хэндл шлем IOCTL. В этом случае запрос попадает сразу на нужный девайс-фильтр. Правда, сам файл должен существовать на момент вызова.

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

ОК, тогда шли не на сам файл, а на том, на котором файл лежит. Ты же сам формируешь путь? Т.е., скажем, сформировал путь "E:\temp.txt", открыл девайс E:, послал на него IOCTL с путем. Запрос сам придет на нужный девайс.

Здравствуйте, angry.andrew, Вы писали:

AA>>>Как я понимаю, ты шлешь IOCTL на специальный CDO. Что если посылать его непосредственно на тот файл, путь к которому сейчас передается в IOCTL? Я имею в виду, открываем этот файл, а потом на его же хэндл шлем IOCTL. В этом случае запрос попадает сразу на нужный девайс-фильтр. Правда, сам файл должен существовать на момент вызова.

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

AA>ОК, тогда шли не на сам файл, а на том, на котором файл лежит. Ты же сам формируешь путь? Т.е., скажем, сформировал путь "E:\temp.txt", открыл девайс E:, послал на него IOCTL с путем. Запрос сам придет на нужный девайс.

попробую, спасибо

AA>ОК, тогда шли не на сам файл, а на том, на котором файл лежит. Ты же сам формируешь путь? Т.е., скажем, сформировал путь "E:\temp.txt", открыл девайс E:, послал на него IOCTL с путем. Запрос сам придет на нужный девайс.

Тут всё правильно, только запрос на открытие (если открывать том как обычно) пойдёт через FS stack, т.е. в фильтре это опять же будет видно как IRP_MJ_CREATE. Если это не смущает — ok, но я бы сделал по-другому. Чтобы избежать лишних IRP_MJ_CREATE в фильтре лучше открыть том напрямую, тогда запрос пойдёт через storage stack и мы его не увидим. Как правильно использовать device direct open, хорошо описано здесь

Автор: Ivan
Дата: 05.10.07

.