Привет всем!
Подскажите, плз, где можно почитать про создание виртуальных дисковых устройств для Windows (аналогично VirtualCD). В какую сторону копать ? В ddk и драйверы файловых систем или есть более поверностный уровень реализации ?

Спасибо заранее,

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

G>Привет всем!
G>Подскажите, плз, где можно почитать про создание виртуальных дисковых устройств для Windows (аналогично VirtualCD). В какую сторону копать ? В ddk и драйверы файловых систем или есть более поверностный уровень реализации ?
очень сильно зависит от того что именно Вы хотите (VirtualCD не видел, пользуюсь DaemonCD):
— просто виртуальный диск который потом можно будет отформатировать под FAT/NTFS/whatever и использовать как обычный: тут нужно создать драйвер который создаст FILE_DEVICE_DISK устройство с флагом FILE_VIRTUAL_VOLUME. если хочется чтобы оно было removable — еще не помешает флажок FILE_REMOVABLE_MEDIA. ну и реализовать всю ф-ть требуемую для такого рода устройств.
— может быть нужно эмулировать более глубоко: class driver to emulate an IDE device disk
это что касается дисковых устройств

а вот с CD/DVD уже немного другая область:
— виртуальный CD driver: можно пойти по пути a filter to the storage class driver
— виртуальный CD driver который будет виден вплоть до aspi layer: вроде бы тут пишут SCSIPORT driver

куда копать?
в сторону DDK + IFS Kit от МС — там есть примеры в т.ч. исходные тексты cdfs/fastfat внутри и еще кое-что
почитать www.ntfsd.org и www.osronline.com

плюс недавно тут список небольшой ссылок по драйверам кидали в соседней ветке... ну и поиск по этому форуму

в сети есть примеры MS RAMDISK (NT4 DDK) и кое-что еще интересное...

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

V>очень сильно зависит от того что именно Вы хотите (VirtualCD не видел, пользуюсь DaemonCD):
V>- просто виртуальный диск который потом можно будет отформатировать под FAT/NTFS/whatever и использовать как обычный: тут нужно создать драйвер который создаст FILE_DEVICE_DISK устройство с флагом FILE_VIRTUAL_VOLUME. если хочется чтобы оно было removable — еще не помешает флажок FILE_REMOVABLE_MEDIA. ну и реализовать всю ф-ть требуемую для такого рода устройств.

В принципе, именно это и надо. Просто я никогда драйверов не писал, поэтому блуждаю во тьме. Может быть есть где-то туториалы и примеры кода по написанию драйверов файловой системы, которые работают с устройствами FILE_DEVICE_DISK ?

V>куда копать?
V>в сторону DDK + IFS Kit от МС — там есть примеры в т.ч. исходные тексты cdfs/fastfat внутри и еще кое-что

А откуда можно скачать IFS Kit ? На сайте MS за него просят длинный рубль...

Спасибо,

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

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

V>>очень сильно зависит от того что именно Вы хотите (VirtualCD не видел, пользуюсь DaemonCD):
V>>- просто виртуальный диск который потом можно будет отформатировать под FAT/NTFS/whatever и использовать как обычный: тут нужно создать драйвер который создаст FILE_DEVICE_DISK устройство с флагом FILE_VIRTUAL_VOLUME. если хочется чтобы оно было removable — еще не помешает флажок FILE_REMOVABLE_MEDIA. ну и реализовать всю ф-ть требуемую для такого рода устройств.

G>В принципе, именно это и надо. Просто я никогда драйверов не писал, поэтому блуждаю во тьме. Может быть есть где-то туториалы и примеры кода по написанию драйверов файловой системы, которые работают с устройствами FILE_DEVICE_DISK ?

посмотрите MS RAMDRIVE в сети и http://www.acc.umu.se/~bosse/
но если честно то вроде бы исходники на последней страничке — ворованные. Я предупредил

G>А откуда можно скачать IFS Kit ? На сайте MS за него просят длинный рубль...
да, но прикол в том, что можно обойтись и без — достаточно скачать ntifs.h из сети там же.

G>Спасибо,
не за что, но если сильно хочется то в правом углу

Здравствуйте, Valerio.

Я установил DDK, но не могу найти нигде в документации сколь-нибудь внятной информации по написанию file system драйвера виртуального диска. Мне необходимо создать драйвер виртуального диска, файлы которого физически будут хранится на удаленном веб-сервере, хотя для пользователся это будут всего лишь файлы на диске X. Драйвер через локальное приложение-диспетчер (связь драйвера с диспетчером может быть осуществлена, например, через named pipe) должен будет соединятся с веб-сервером для получения table of contents и для update / commit данных. Другими словами, нужно эмулировать работу с файлами, хранящимися в удаленной базе данных так, чтобы пользователь смог работать с ними как с обычными файлами на обычном диске.
Возможно ли это реализовать в обычном FS драйвере, эмулирующем FILE_DEVICE_DISK. Если да, то нужен ли здесь class driver для IDE device disk или можно обойтись обычным драйвером ? И еще вопрос, какой callback необходимо реализовать в драйвере FS, для того, чтобы управлять загрузкой table of contents на FILE_DEVICE_DISK? Возможно ли это вообще, или загрузка списка файлов сокрыта от разработчика драйвера ?

Извините за большое количество вопросов, для меня это новая тема, поэтому много не совсем понятного. Спасибо за понимание и помощь!

для разработки драйверов файловых систем включая подобные вещи предназначен не DDK а IFS Kit

в DDK драйвер виртуального диска RAMDRIVE был в версии для NT4 очень давно
ХИНТ: но по прежнему можно пользоваться гуглом

по поводу задачи: а про WebDAV Вы слышали — иожет быть велосипед уже изобретен и поставляется с Офисом 2000 и ХР в базовой поставке? это правда не отдельный диск но всегда можно замонтировать WebDAV папку на какую-то свободную букву...

не понял какой диспетчер имеется ввиду и зачем с ним связь по именованные каналы?
с драйвером обычно общается локальный процесс через внутрений IOCTL протокол

связь с удаленным сервером должна быть сделана скорее всего на уровне TDI из драйвера

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

IDE class driver конечно в этой задаче не нужен

каталоги действительно через IRP_MN_QUERY_DIRECTORY поддерживаются — ответил в соседней ветке

G> Я установил DDK, но не могу найти нигде в документации сколь-нибудь внятной информации по написанию file system драйвера виртуального диска. Мне необходимо создать драйвер виртуального диска, файлы которого физически будут хранится на удаленном веб-сервере, хотя для пользователся это будут всего лишь файлы на диске X. Драйвер через локальное приложение-диспетчер (связь драйвера с диспетчером может быть осуществлена, например, через named pipe) должен будет соединятся с веб-сервером для получения table of contents и для update / commit данных. Другими словами, нужно эмулировать работу с файлами, хранящимися в удаленной базе данных так, чтобы пользователь смог работать с ними как с обычными файлами на обычном диске.
G> Возможно ли это реализовать в обычном FS драйвере, эмулирующем FILE_DEVICE_DISK. Если да, то нужен ли здесь class driver для IDE device disk или можно обойтись обычным драйвером ? И еще вопрос, какой callback необходимо реализовать в драйвере FS, для того, чтобы управлять загрузкой table of contents на FILE_DEVICE_DISK? Возможно ли это вообще, или загрузка списка файлов сокрыта от разработчика драйвера ?
G> Извините за большое количество вопросов, для меня это новая тема, поэтому много не совсем понятного. Спасибо за понимание и помощь!

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

V>по поводу задачи: а про WebDAV Вы слышали — иожет быть велосипед уже изобретен и поставляется с Офисом 2000 и ХР в базовой поставке? это правда не отдельный диск но всегда можно замонтировать WebDAV папку на какую-то свободную букву...

К сожалению на WebDAV заказчики не согласны, хотя идея системы очень похожа.. У них есть свои взгляды на этот счет. Вероятно, просто, целевые системы не ограничиваются WinXP, и не на всех стоит Office.

V>связь с удаленным сервером должна быть сделана скорее всего на уровне TDI из драйвера

Не хочется загружать драйвер кодом, реализующим передачу данных в удаленную базу и обратно. Это усложнение приведет к значительным трудностям при написании и отладке, или я не прав ? Мне кажется, более рационально перенести выполнение кода, реализующего логику связи с базой ревизий, в user-mode.

V>не понял какой диспетчер имеется ввиду и зачем с ним связь по именованные каналы?
V>с драйвером обычно общается локальный процесс через внутрений IOCTL протокол

При этом хотелось бы, чтобы драйвер сам мог посылать информацию в базу ревизий, когда ему это будет необходимо (обновление, создание новых файлов), поэтому IOCTL, который, как я понял, может передавать данные в host process только в ответ на I/O запросы, не подходит. Вполне возможно, что я ошибаюсь, тогда каким образом драйвер может отсылать данные в host process в любой момент, когда это понадобиться ?
Отсюда было желание организовать pipe,через который можно будет гонять данные из драйвера в некоторое приложение-службу (назовем его диспетчером), работающее в user-mode и реализующее логику общения с базой данных ревизий.

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

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

Спасибо!

З.Ы: Мне хватит ntifs.h для получения всех приемуществ, которые дает IFS ? Где можно взять документацию по IFS ?

Спасибо еще раз!

Здравствуйте, Valerio!

Насчет приложения-диспетчера, вот, что написано в буке "Windows NT File System Internals" (O'Reilly):

The filter driver may either use the services of the original
target of the I/O request, or use the services of other user-mode or kernelmode
software to provide value-added functionality.

Именно это обеспечение value-added functionality я и имел ввиду, подразумевая под ней синхронизацию (связь) с базой ревизий.

Спасибо,

Здравствуйте, Valerio!

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

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

Спасибо,

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

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

V>>по поводу задачи: а про WebDAV Вы слышали — иожет быть велосипед уже изобретен и поставляется с Офисом 2000 и ХР в базовой поставке? это правда не отдельный диск но всегда можно замонтировать WebDAV папку на какую-то свободную букву...

G>К сожалению на WebDAV заказчики не согласны, хотя идея системы очень похожа.. У них есть свои взгляды на этот счет. Вероятно, просто, целевые системы не ограничиваются WinXP, и не на всех стоит Office.
знакомо

V>>связь с удаленным сервером должна быть сделана скорее всего на уровне TDI из драйвера

G>Не хочется загружать драйвер кодом, реализующим передачу данных в удаленную базу и обратно. Это усложнение приведет к значительным трудностям при написании и отладке, или я не прав ? Мне кажется, более рационально перенести выполнение кода, реализующего логику связи с базой ревизий, в user-mode.
выбирайте между complexity & perfomance goal

V>>не понял какой диспетчер имеется ввиду и зачем с ним связь по именованные каналы?
V>>с драйвером обычно общается локальный процесс через внутрений IOCTL протокол

G>При этом хотелось бы, чтобы драйвер сам мог посылать информацию в базу ревизий, когда ему это будет необходимо (обновление, создание новых файлов), поэтому IOCTL, который, как я понял, может передавать данные в host process только в ответ на I/O запросы, не подходит. Вполне возможно, что я ошибаюсь, тогда каким образом драйвер может отсылать данные в host process в любой момент, когда это понадобиться ?
G>Отсюда было желание организовать pipe,через который можно будет гонять данные из драйвера в некоторое приложение-службу (назовем его диспетчером), работающее в user-mode и реализующее логику общения с базой данных ревизий.

это можно сделать способом каким видели общение с драйвером разработчики ядра, а именно pending IRP queue: скажем вспомогательный сервис в одном или многих потоках накидывает IOCTL которые драйвер в виде у себя держит в виде очереди pending IRP и по мере появления данных завершает — поток просыпается и получает от драйвера что-то (что вполне можно интерпретировать как ЦУ) и после обработки опять кидает вниз IOCTL запрос.

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

G>Конечно, в данном случае мы никуда не денемся от динамической генерации содержимого и, действительно, здесь фильтр файловой системы — наш друг (осталось только его убедить в этом ). Буду работать в этом направлении.

G>Спасибо!

G>З.Ы: Мне хватит ntifs.h для получения всех приемуществ, которые дает IFS ? Где можно взять документацию по IFS ?
документацию взять в самом IFS Kit
по идее да, качайте посвежее в инете а если чего нет — добавляйте руками
www.osronline.com + NTFSD mailing list is really your friend here

G>Спасибо еще раз!
здесь спасибо справа сверху

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

G>Здравствуйте, Valerio!

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

G>Гм... Появился вопрос: зачем нам драйвер-фильтр, если мы можем организовать обработчики запросов самого драйвера виртуального диска так чтобы он ходил в базу через приложение-диспетчер ? Насколько я знаю, драйвер-фильтр пишется для какого-то определенного диска, когда функиональность драйвера этого диска не удовлетворяет новым потребностям. Но я же сам буду реализовывать целевой драйвер, управляющий моим виртуальным Web-диском и смогу реализовать прямо в нем всю необходимую мне функиональность связи с приложением-диспетчером. Зачем писать два драйвера, если можно написать один ?
выберите что Вам нужно: сектора диска или файлы
соотв и пишется либо свой диск (или его фильтр) либо FSD (или ее фильтр)

G>Спасибо,

Здравствуйте, Valerio!

Допустим, я реализую до конца свой file system driver, который будет управлять некоторым FILE_DISK_DEVICE. Как обычно, устройство будет создаваться в DriverEntry вызовом IoCreateDevice с соответствующими флагами. Затем, я реализую необходмые экпорты для обработки IRP и callback'и для Cache manager'а. После этого, я загружу свой драйвер из некоторого приложения, запустив его, как сервис с флагом SERVICE_KERNEL_DRIVER. Могу ли я надеятся, что после этого новый диск, управляемый моим драйвером, будет доступен для просмотра стандартными средствами (например, через "Мой компьютер" или какой-нибудь файловый manager) или для взаимодействия с пользователем необходимо реализовывать какие-то дополнительные функии ?

Спасибо!

Здравствуйте, Valerio!

А каков минимальный набор IRP Dispatch entry points, которые необходимо реализовать, чтобы получить возможность просматривать содержимое директории диска, управляемого данным драйвером ? Понятно, что необходимым является IRP_MJ_DIRECTORY_CONTROL (с минором IRP_MN_QUERY_DIRECTORY) для получения данных о директории. Но скорее всего существует какой-то минимум, без которого FSD вообще не будет функционировать.. Интересно было бы узнать, какие запросы относятся к этой группе.

И еще есть вопрос, каким образом помещать в Driver Verifier свои драйвера для проверки ? Являтся ли эта программа единственной в своем роде или наиболее оптимальной ? Если нет, то какие существуют аналоги ?

Спасибо!

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

G>Здравствуйте, Valerio!

G>А каков минимальный набор IRP Dispatch entry points, которые необходимо реализовать, чтобы получить возможность просматривать содержимое директории диска, управляемого данным драйвером ? Понятно, что необходимым является IRP_MJ_DIRECTORY_CONTROL (с минором IRP_MN_QUERY_DIRECTORY) для получения данных о директории. Но скорее всего существует какой-то минимум, без которого FSD вообще не будет функционировать.. Интересно было бы узнать, какие запросы относятся к этой группе.
стоп. мы говорим уже не о виртуальном диске а о фильтре файловой системы (поверх любого диска)?

если о виртуальном диске то у себя я использовал

    DriverObject->MajorFunction[IRP_MJ_CREATE]          = Create;
    DriverObject->MajorFunction[IRP_MJ_CLOSE]           = Close;
    DriverObject->MajorFunction[IRP_MJ_READ]            = ReadWrite;
    DriverObject->MajorFunction[IRP_MJ_WRITE]           = ReadWrite;
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL]  = DeviceControl;

если о фильтре — то решение о том что именно фильтровать принимать Вам (зависит от ТЗ)
все остальные IRP_MJ_* (равно как и FastIo*) лучше закрыть заглушками которые просто отправляют запрос следующему драйверу вниз. Смотрите как это делает filemon или filespy from IFS Kit

FSD тут совсем не причем — фильтр это несколько другая вещь чем сама файловая система и совсем другая вещь чем драйвер виртуального диска.

G>И еще есть вопрос, каким образом помещать в Driver Verifier свои драйвера для проверки ? Являтся ли эта программа единственной в своем роде или наиболее оптимальной ? Если нет, то какие существуют аналоги ?
по driver verifier куча информации в статьях MSDN и есть статья от Руссиновича в журнале Windows 2000 — сейчас там другое уже название кажется — не помню

G>Спасибо!

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

G>Здравствуйте, Valerio!

G>Допустим, я реализую до конца свой file system driver, который будет управлять некоторым FILE_DISK_DEVICE. Как обычно, устройство будет создаваться в DriverEntry вызовом IoCreateDevice с соответствующими флагами. Затем, я реализую необходмые экпорты для обработки IRP и callback'и для Cache manager'а. После этого, я загружу свой драйвер из некоторого приложения, запустив его, как сервис с флагом SERVICE_KERNEL_DRIVER. Могу ли я надеятся, что после этого новый диск, управляемый моим драйвером, будет доступен для просмотра стандартными средствами (например, через "Мой компьютер" или какой-нибудь файловый manager) или для взаимодействия с пользователем необходимо реализовывать какие-то дополнительные функии ?
надеяться можете, если все сделаете правильно
кстати, с Сс связываться необязательно вот так вот сразу: это необязательное требование, подтягивать Сс

G>Спасибо!

Здравствуйте, Valerio!

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

ЗАДАЧА: Реализовать файловую систему, использующую в виде хранилища данных удаленную базу данных. Доступ к базе должен осуществляться через некоторый Web-сервис, предоставляющий свой SOAP интерфейс. Следует учесть, что Web-сервис не предполагает наличие механизмов сериализации доступа к файлам и умеет просто получать данные о файлах и директориях, доставать файлы из базы и записывать их туда.

РЕШЕНИЕ: Предполагается реализовать двухуровневую систему. Первый уровень будет ответственнен за общение с IO Manger'ом, второй — за общение с удаленным Web-сервисом. Первый уровень будет реализован в виде File System драйвера, второй — в виде NT-сервиса пользовательского режима. Протокол их взаимодействия основан на IOCTL + Pending IRP (спасибо за совет ). Можно было бы использовать традиционную технику и реализовывать двухуровневый драйвер, но тогда всю рутину общения с удаленным сервисом через SOAP пришлось бы зашивать в драйвер нижнего уровня, а это значительно более трудоемко и опасно (по времени), чем реализация этого протокола в пользовательском режиме (это отвечает требованиям заказчика).

ПОРЯДОК РАБОТЫ: FSD будет получать IRP от IO Manager'а, инициировать запросы к сервису пользовательского режима, ожидать ответ, заполнять IRP корректными данными и завершать его. Для этого, сначала необходимо будет получить IOCTL от сервиса пользовательского режима и ответить на него, когда произойдет ожидаемое событие (создание файла, чтение файла, просмотр содержимого директории). Затем, необходимо будет дождаться очередного IOCTL от сервиса, который будет содержать ответ на запрос (например, данные читаемого файла), поместить их в IRP и завершить запрос.

Вот краткое описание концепции. Я прошу вас оценить критически мой метод реализации и сказать, что с вашей точки зрения не корректно или слишком амбициозно.

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

Заранее большое спасибо! Надеюсь на новые ценные советы.

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

Gwynn, это интересно но за последний месяц Вы уже не первый и даже не третий, кто с такой задачей ко мне обращается

G>ЗАДАЧА: Реализовать файловую систему, использующую в виде хранилища данных удаленную базу данных. Доступ к базе должен осуществляться через некоторый Web-сервис, предоставляющий свой SOAP интерфейс. Следует учесть, что Web-сервис не предполагает наличие механизмов сериализации доступа к файлам и умеет просто получать данные о файлах и директориях, доставать файлы из базы и записывать их туда.

чем не нравятся стандартные решения? WebDAV redirector? если волнует безопасность и нужен свой протокол — что мешает просто фильтровать иенно этот девайс (file system filter driver for WebDAV redirector)? ответ наверняка будет стандартный, но хотелось бы его все равно узнать сначала

G>РЕШЕНИЕ: Предполагается реализовать двухуровневую систему. Первый уровень будет ответственнен за общение с IO Manger'ом, второй — за общение с удаленным Web-сервисом. Первый уровень будет реализован в виде File System драйвера, второй — в виде NT-сервиса пользовательского режима. Протокол их взаимодействия основан на IOCTL + Pending IRP (спасибо за совет ). Можно было бы использовать традиционную технику и реализовывать двухуровневый драйвер, но тогда всю рутину общения с удаленным сервисом через SOAP пришлось бы зашивать в драйвер нижнего уровня, а это значительно более трудоемко и опасно (по времени), чем реализация этого протокола в пользовательском режиме (это отвечает требованиям заказчика).
есть мнение что это уже давно не так страшно — что-то делать на уровне ядра
впрочем, обоснование разумное

G>ПОРЯДОК РАБОТЫ: FSD будет получать IRP от IO Manager'а, инициировать запросы к сервису пользовательского режима, ожидать ответ, заполнять IRP корректными данными и завершать его. Для этого, сначала необходимо будет получить IOCTL от сервиса пользовательского режима и ответить на него, когда произойдет ожидаемое событие (создание файла, чтение файла, просмотр содержимого директории). Затем, необходимо будет дождаться очередного IOCTL от сервиса, который будет содержать ответ на запрос (например, данные читаемого файла), поместить их в IRP и завершить запрос.

G>Вот краткое описание концепции. Я прошу вас оценить критически мой метод реализации и сказать, что с вашей точки зрения не корректно или слишком амбициозно.
все гениальное просто. это знают все.
но боюсь что здесь можно и сказать наоборот: все простое — гениально

Если серьезно, то идея правильная, других вариантов впрочем особо и нет, если через Ваш Webservice только действовать. Если у Вас получится все сделать по этой схеме (без деадлоков со своими же сервисами и другими фильтрами-драйверами) и чтобы все стабильно работало на серверах в режиме 24х7 — это будет реально круто Однако такие вещи уже есть на рынке и довольно давно, подумайте еще раз о фильтре WebDAV вместо своей его реализации?

Идеологически пожалуй не придерешься, but devil in the details, as usual. Можно прямо сейчас растечься мыслью по древу и написать трактат, но у меня нет столько времени (да и желания).

Наверное стоит начать, а там будет видно? если же сейчас у Вас стадия планирования-оценки, то здесь год на драйвер будет весьма агрессивным планом (если нет готовых наработок в этой области), ИМХО Впрочем, я про себя говорю, как у Вас пойдет я не знаю.

G>Если можно, то напишите, пожалуйста, список MajorFunctions, которые необходимо обязательно реализовать в драйвере файловой системы, который я описал выше.
список зависит от конкретных требований и возникающих в процессе ситуаций: базовые конечно все потребуют обработки, fast IO handlers можно не трогать пока особо — это всплывет если понадобится решать проблемы производительности или еще какие-нибудь (в том что они будут можно не сомневаться).

вероятно, Вам нужно посмотреть в поиске мою дискуссию со Сторожем о paging IO — я вижу тут решение в том что Вам минимально нужно обрабатываеть только эти запросы к диску (не к кэшу) и соотв. в этом случае не нужно будет волноваться про FastIO (до поры). Поиск поможет.

G>Заранее большое спасибо! Надеюсь на новые ценные советы.
заранее то зачем Успехов!

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

V>чем не нравятся стандартные решения? WebDAV redirector? если волнует безопасность и нужен свой протокол — что мешает просто фильтровать иенно этот девайс (file system filter driver for WebDAV redirector)? ответ наверняка будет стандартный, но хотелось бы его все равно узнать сначала

Дело в том, что уже написан (не мной) вполне работоспособный и вышедший на рынок "CMS" Web Service, который занимается управлением репозиториями файлов. Мне поручено решить задачу о прикручивании к этому сервису файловой системы. Поэтому о WebDAV редиректоре речи не идет, к сожалению. Придется изобрести очередной велосипед

Возникло еще несколько насущных вопросов по FSD. Буду благодарен за любые советы.

1. Я реализую следующие IRP функции:

IRP_MJ_CREATE — для симуляции создания файла на диске
IRP_MJ_CLOSE – для симуляции закрытия файла на диске
IRP_MJ_READ – для чтения файла
IRP_MJ_WRITE – для записи в файл
IRP_MJ_QUERY_INFORMATION – для получения информации о файле
IRP_MJ_SET_INFORMATION – для задания информации о файле
IRP_MJ_DEVICE_CONTROL – для управления драйвером из user-mode сервиса через Win32 API вызов DeviceIoControl ()
IRP_MJ_FILE_SYSTEM_CONTROL – для mount / unmout диска
IRP_MJ_DIRECTORY_CONTROL – для получения информации о директории через функцию IRM_MN_QUERY_DIRECTORY

Как вы думаете, понадобятся ли FSD какие-либо еще IRP функции для нормальной работы? Правильно ли я оценил характер работы каждой из функций?

2. В процессе разработки возникает следующая практическая проблема: можно ли реализовать НЕ ВСЕ описанные выше IRP функции и успешно работать с драйвером? Это необходимо для нормального тестирования, нельзя же реализовать все сразу, а драйвера нижнего уровня, для которого я мог бы поставить заглушку, в данной системе нет. Что будет, если IO Manager передаст драйверу, например IRP_MJ_SET_INFORMATION, а эта функция не будет реализована в драйвере, а точнее,

DriverObject->MajorFunctions[IRP_MJ_SET_INFORMATION] = NULL;

?
Нормально ли, что на данном этапе разработки

DriverObject->FastIoDispatch = NULL;

?
Если нулевые указатели в данном случае будут приводить к краху системы, то какие заглушки можно поставить в данном случае ?

3. Действительно ли IRP_MN_MOUNT… (не помню, как точно называется, минорная функция IRP_MJ_FILE_SYSTEM_CONTROL) вызывается при создании объекта файловой системы? Или нужно каким-то другим образом инициировать mount диска? Тогда каким?

4. Какую пользу для драйвера файловой системы приносит загрузка кода в определенный сегмент памяти с помощью директивы компилятора

#pragma once code_seg (MY_CODE_SEGMENT)

?

Большое спасибо за советы!
Best wishes,

G>Дело в том, что уже написан (не мной) вполне работоспособный и вышедший на рынок "CMS" Web Service, который занимается управлением репозиториями файлов. Мне поручено решить задачу о прикручивании к этому сервису файловой системы. Поэтому о WebDAV редиректоре речи не идет, к сожалению. Придется изобрести очередной велосипед
yes, as usual

G>IRP_MJ_SET_INFORMATION – для задания информации о файле
также для удаления, помощи в выделении места на диске и переименовывания (полный список в DDK/IFS/headers)

G>Как вы думаете, понадобятся ли FSD какие-либо еще IRP функции для нормальной работы? Правильно ли я оценил характер работы каждой из функций?
в целом все правильно, что либо еще может понадобиться
не знаю деталей Вашего ТЗ

G>2. В процессе разработки возникает следующая практическая проблема: можно ли реализовать НЕ ВСЕ описанные выше IRP функции и успешно работать с драйвером? Это необходимо для нормального тестирования, нельзя же реализовать все сразу, а драйвера нижнего уровня, для которого я мог бы поставить заглушку, в данной системе нет. Что будет, если IO Manager передаст драйверу, например IRP_MJ_SET_INFORMATION, а эта функция не будет реализована в драйвере, а точнее,

G>

G>DriverObject->MajorFunctions[IRP_MJ_SET_INFORMATION] = NULL;
G>

G>?
нет, если Вы поддерживаете вызов, нужно об этом сказать вызывающему. Если Вы начнете на все подряд возвращать 0, там решат что это дело совсем не реализовано. Нужно установить заглушку которая будет отправлять пакет драйверу вниз по цепочке:

for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) {
    DriverObject->MajorFunction[i] = SpyDispatch;
}
DriverObject->MajorFunction[IRP_MJ_CREATE] = SpyCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = SpyClose;
DriverObject->MajorFunction[IRP_MJ_FILE_SYSTEM_CONTROL] = SpyFsControl;

G>Нормально ли, что на данном этапе разработки

G>

G>DriverObject->FastIoDispatch = NULL; 
G>

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

G>3. Действительно ли IRP_MN_MOUNT… (не помню, как точно называется, минорная функция IRP_MJ_FILE_SYSTEM_CONTROL) вызывается при создании объекта файловой системы? Или нужно каким-то другим образом инициировать mount диска? Тогда каким?
Вам нужно срочно взглянуть в исходники sfilter

G>4. Какую пользу для драйвера файловой системы приносит загрузка кода в определенный сегмент памяти с помощью директивы компилятора

G>

G>#pragma once code_seg (MY_CODE_SEGMENT)
G>

G>?
такую же как и для всех других: paged память может быть выгружена в своп и таким образом освободить еще пару страниц опаративной памяти... но будьте осторожны — если код-данные понадобятся где-либо выше APC_LEVEL то уже подкачка с диска не пройдет — взрыв.

кстати говоря в FastFat FastIo процедуры (и не только) paged

G>Большое спасибо за советы!
в правом верхнем углу...

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

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

V>

V>for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) {
V>    DriverObject->MajorFunction[i] = SpyDispatch;
V>}
V>DriverObject->MajorFunction[IRP_MJ_CREATE] = SpyCreate;
V>DriverObject->MajorFunction[IRP_MJ_CLOSE] = SpyClose;
V>DriverObject->MajorFunction[IRP_MJ_FILE_SYSTEM_CONTROL] = SpyFsControl;
V>

А если нижнего драйвера нет? У меня стек драйверов состоит всего из одного доайвера высокого уровня — собственно FSD. Я не пользуюсь какими-либо физическими устройствами, то есть пользуюсь обычным NTFS для хранения файлов и делаю это в user-mode service. А драйвер просто делегирует все вызовы IO Manager'а и фильтров в user-mode service, где и происходит основная чать обработки собственно файлов. Поэтому у моего FSD нет более низкого драйвера и перенаправлять вниз по цепочке запросы я не могу. Как в таком случае может быть реализована заглушка SpyDispatch, если "заглушать" нечем? Может надо возвращать ошибку или какой-нибудь NOT_IMPEMENTED из диспетчерских точек ? Как на это отреагирует Driver Verifier ?


G>>

G>>DriverObject->FastIoDispatch = NULL; 
G>>

G>>?
G>>Если нулевые указатели в данном случае будут приводить к краху системы, то какие заглушки можно поставить в данном случае ?
V>в принципе это нормально (обнулить всю FastIO таблицу) но тут уже проблемы могут быть не у Вас, а у фильтров сверху Вас (кривых довольно много), так что лучше аналогично сделать FastIO заглушку.

Аналогичный вопрос, что вы имеете ввиду под заглушкой для FastIO в описанном выше случае?

V>Вам нужно срочно взглянуть в исходники sfilter

Осталось найти IFS Или есть отдельные источники, из которых можно вытянуть этот пример? Если есть возможность, пришлите мне, пожалуйста, сорцы sfilter на . Найти же халявный IFS пока не получается

G>>Большое спасибо за советы!
V>в правом верхнем углу...

Напрашивается вопрос: а что там, в правом верхнем углу ? Пятый раз смотрю туда и ничего не вижу...

Спасибо,