retval = hookExt->FileSystem->DriverObject->FastIoDispatch->FastIoRead(
FileObject, FileOffset, Length,
Wait, LockKey, Buffer, IoStatus, hookExt->FileSystem );
File system driver
Всем привет!
Пытаюсь написать драйвер файловой системы. Он в общем-то начал работать, но только с теми программами, которые не используют отображение файлов на память (MapViewOfFile и все такое). Не подскажет ли кто, достаточно ли для маппинга стандартных запросов (IRP_MJ_XXX) или обязательно требуется реализовывать FAST_IO_XXX? И если без последних не обойтись, то где можно про них почитать? Хелп по DDK который у меня стоит (3790.1830) злорадно заявляет, что "Unfortunately, at the present time Fast I/O is not documented" и обещает в следующих версиях опубликовать.
Заранее спасибо всем, кто захочет помочь.
Пытаюсь написать драйвер файловой системы. Он в общем-то начал работать, но только с теми программами, которые не используют отображение файлов на память (MapViewOfFile и все такое). Не подскажет ли кто, достаточно ли для маппинга стандартных запросов (IRP_MJ_XXX) или обязательно требуется реализовывать FAST_IO_XXX? И если без последних не обойтись, то где можно про них почитать? Хелп по DDK который у меня стоит (3790.1830) злорадно заявляет, что "Unfortunately, at the present time Fast I/O is not documented" и обещает в следующих версиях опубликовать.
Заранее спасибо всем, кто захочет помочь.
я хотел бы помочь, реально я не писал таких вещей, но если подумать логично (официально), если они не документированы, значит никто не сможет написать драйвер ФС с использованием запросов FAST_IO_XXX , значит не надо.........
Цитата: Ramon
FSDK я здесь уже цитировал, и на странице мелкомягкой тоже был. Дальше списка функций они не идут. Тот список я и в хедерах видел. Интересно было бы узнать назначение и параметры основных функций или точно удостовериться, что можно обойтись без них и искать багу. Хотя я вроде весь код три раза перелопатил...
А исходники filemon не дают ответа?
Цитата: Green
А исходники filemon не дают ответа?
Filemon будучи фильтр-драйвером может себе позволить такие штуки:
Код:
Т.е. он просто пересылает запрос нижестоящему драйверу и сообщает информацию о запросе юзермодному приложению, которое потом на основе своих фильтров решает показывать его пользователю или не стоит. А что там этот драйвер с его запросом на самом деле творит увы неизвестно :(
TrueCrypt тоже не дает ответа на мой вопрос. Он работает уровнем ниже и к нему приходят только запросы на чтение/запись отдельных блоков "диска", никак к файлам не привязанные. Так что этот точно может без FAST_IO обходиться. И обходится успешно.
Вот сейчас в DDK-шных примерах обнаружил несколько реализованных функций из этого набора. Буду пробовать создать нечто похожее.
Цитата: right_systems
Вот сейчас в DDK-шных примерах обнаружил несколько реализованных функций из этого набора. Буду пробовать создать нечто похожее.
Попробуй ещё взглянуть на исходники Ext2FSD.
С Fast I/O разобрался. Они просто призвани заменить IRP, и их обработка не является обязательным.
Возникла новая проблема. Может кто сталкивался или хотя бы имеет представление о причинах.
T: - диск, соотвествующий моему устройству.
CreateFileW отрабатывает нормально и возвращает вполне рабочий HANDLE. Я могу получать размер этого файла, применять к нему ReadFile и т.д. Но вот CreateFileMapping не срабатывает ни при каких условиях. GetLastError возвращает какой-то мифический код 193 ("%1 is not a valid Win32 application"). Причем в драйвер никакие запросы не приходят.
Собственно вопрос: Может ли это как-то зависеть от флагов, выставленных в парметрах устройства? Сейчас оно у меня объявлено как FILE_DEVICE_DISK_FILE_SYSTEM (пробовал и FILE_DEVICE_NETWORK_FILE_SYSTEM), режим доступа - Neither (пытался так же DO_DIRECT_IO).
Возникла новая проблема. Может кто сталкивался или хотя бы имеет представление о причинах.
Код:
HANDLE hFile = CreateFileW(L"T:\\2.txt", GENERIC_READ, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if (hFile == INVALID_HANDLE_VALUE)
return;
HANDLE hMap = CreateFileMapping(hFile, 0, PAGE_READ_ONLY, 0, 10, 0);
if (hFile == INVALID_HANDLE_VALUE)
return;
HANDLE hMap = CreateFileMapping(hFile, 0, PAGE_READ_ONLY, 0, 10, 0);
T: - диск, соотвествующий моему устройству.
CreateFileW отрабатывает нормально и возвращает вполне рабочий HANDLE. Я могу получать размер этого файла, применять к нему ReadFile и т.д. Но вот CreateFileMapping не срабатывает ни при каких условиях. GetLastError возвращает какой-то мифический код 193 ("%1 is not a valid Win32 application"). Причем в драйвер никакие запросы не приходят.
Собственно вопрос: Может ли это как-то зависеть от флагов, выставленных в парметрах устройства? Сейчас оно у меня объявлено как FILE_DEVICE_DISK_FILE_SYSTEM (пробовал и FILE_DEVICE_NETWORK_FILE_SYSTEM), режим доступа - Neither (пытался так же DO_DIRECT_IO).
сама ошибка "%1 is not a valid Win32 application" заставляет задуматься, PAGE_READ_ONLY ты наверно хотел написать PAGE_READONLY, или может у тебя где объявлена константа PAGE_READ_ONLY с другим значением
PAGE_READONLY конечно. Просто на 2-х компах пишу: один тестовый и этот код как раз был на нем. По сети тащить не хотелось - типа наберу быстрее :). В общем-то Notepad вылетает с той же ошибкой. Хотя там все правильно написано и он тоже мапит открываемые файлы.
Цитата: right_systems
GetLastError возвращает какой-то мифический код 193 ("%1 is not a valid Win32 application").
(только догадка) может ты пытаешься мэпить в .NET приложении
Если бы так :-( Приложение MFC. Кроме того как я уже говорил, у Notepad та же беда. А уж он-то точно не .NET
ещё одна глупая догадка: есть такая константа SEC_IMAGE при указании которой файл мепится как экзешник, посмотри может где-то выставлен этот флаг.......