Всем привет!
Появился такой вопрос — можно ли из минифильтра, который аттачится к сетевому редиректору (LanmanRedirector),получить тип диска (Removable или Fixed)? Или вообще никак нельзя такое предпринять? Как тогда система распознаёт истинную файловую систему удалённого устройства и его размер?
Re: Работа с сетевым диском из ядра
От:
Аноним
Дата:
07.12.12 20:29
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Всем привет! А>Появился такой вопрос — можно ли из минифильтра, который аттачится к сетевому редиректору (LanmanRedirector),получить тип диска (Removable или Fixed)? Или вообще никак нельзя такое предпринять? Как тогда система распознаёт истинную файловую систему удалённого устройства и его размер?
Никто не подскажет? Может быть господин x64 поможет?
Слушай господина, раб, повелеваю взять снифер и самому убедиться, что данные передаются по SMB и файловый фильтр здесь не поможет. Но зато, о ничтожный раб мой, можно попробовать FltQueryVolumeInformationFile() с классом FileFsAttributeInformation, ну или же WMI-классы вроде Win32_LogicalDisk.
JID: x64j@jabber.ru
Re[3]: Работа с сетевым диском из ядра
От:
Аноним
Дата:
08.12.12 18:30
Оценка:
Здравствуйте, x64, Вы писали:
А>>Может быть господин x64 поможет?
x64>Слушай господина, раб, повелеваю взять снифер и самому убедиться, что данные передаются по SMB и файловый фильтр здесь не поможет. Но зато, о ничтожный раб мой, можно попробовать FltQueryVolumeInformationFile() с классом FileFsAttributeInformation, ну или же WMI-классы вроде Win32_LogicalDisk.
Раб выполнил все Ваши советы x64,но ничего не получилось...все запросы должны адресоваться либо файловому объекту либо объекту в storage-стэке...Почитал у Руссиновича про Lanmanredirector,но там ничего конкретного,только общие понятия.Как я понимаю на стороне сервера нельзя определить тип mapped-диска,не обращаясь к клиенту и не разбирая SMB протокол?
Какой бестолковый раб попался.
Как именно пробовал и что именно "не получилось"?
А>...все запросы должны адресоваться либо файловому объекту...
Да, без всяких "либо".
А>...либо объекту в storage-стэке...
Этот стек здесь точно ни при чём.
А>Почитал у Руссиновича про Lanmanredirector,но там ничего конкретного,только общие понятия.
Я эти книжки последнее время вообще ни воспринимаю.
Такое впечатление, что написаны для админов, но не для системщиков.
А>Как я понимаю на стороне сервера нельзя определить тип mapped-диска,не обращаясь к клиенту и не разбирая SMB протокол?
Неправильно понимаешь, запрос IRP_MJ_QUERY_VOLUME_INFORMATION, адресованный соответствующему сетевому (мини-)редиректору, выливается в итоге как раз в SMB-запрос, а стало быть, самому слать этот запрос нет никакой необходимости. В случае запроса, на серверной стороне будет выполнен тот же query volume information на хендл корневой папки шары, но уже локально, разумеется. Думаю, ты что-то делаешь не так.
JID: x64j@jabber.ru
Re[5]: Работа с сетевым диском из ядра
От:
Аноним
Дата:
08.12.12 20:19
Оценка:
x64,правильно ли я понимаю тот факт,что имея только один фильтр на сервере(там где диск замаплен), нельзя получить информацию о типе реального устройства (диска) на который производится маппинг? Нужен ещё и фильтр на стороне клиента, а потом всю полученную информацию с сервера и клиента связать?Другими словами тип устройства (диска — fixed/removable) не передаётся на серверную часть?
А>x64,правильно ли я понимаю тот факт,что имея только один фильтр на сервере(там где диск замаплен), нельзя получить информацию о типе реального устройства (диска) на который производится маппинг? Нужен ещё и фильтр на стороне клиента, а потом всю полученную информацию с сервера и клиента связать?Другими словами тип устройства (диска — fixed/removable) не передаётся на серверную часть?
А раб, ко всему прочему, ещё и ленивый, ведь казалось бы, заглянуть в доку, увидеть там FileFsDeviceInformation, флаг FILE_REMOVABLE_MEDIA в структуре девайса, написать чуть кода, проверить, так нет же, скорее на форум, благо здесь всегда найдётся пара дураков, которым "нечего делать". Хотя с другой стороны, получше тем для обсуждения что-то не вижу, так что... В старых версиях Windows эта информация не возвращалась редиректором, т.е. возвращались некие стандартные флаги типа FILE_REMOTE_DEVICE и всё, реально никто запроса к серверу не делал, как сейчас дела обстоят — не в курсе, полагаю, ничего не изменилось. А даже если бы и изменилось не забываем, что мы сейчас говорим о стандартном системном редиректоре, а между тем в системе их может быть установлено сколь угодно много (это ещё не считая фильтров) и каждый может монтировать свои сетевые диски, а как они обрабатывают те или иные FS-запросы — тут бабка надвое сказала. Другими словами, лучше всего или фильтровать сетевые запросы (и учитывать, что в качестве транспорта может быть не голый tcp/smb, а, например, каналы или что там взбредёт в голову разработчику), или получать необходимую информацию таки на сервере. И да, ты перепутал клиент с сервером в своём сообщении.
JID: x64j@jabber.ru
Re[7]: Работа с сетевым диском из ядра
От:
Аноним
Дата:
11.12.12 09:45
Оценка:
x64,спасибо тебе большое за помощь!
Интересно было бы узнать каким бы образом ты решал бы эту проблему — через перехват сетевого трафика или минифильтром файловой системы?
А>Проблему перехвата данных, которые передаются на сетевой диск.
Ну давай, давай, ещё более общие слова придумай, останешься вообще без помощи.
JID: x64j@jabber.ru
Re[11]: Работа с сетевым диском из ядра
От:
Аноним
Дата:
12.12.12 08:49
Оценка:
x64>Ну давай, давай, ещё более общие слова придумай, останешься вообще без помощи.
Извини, теперь более предметно :
— когда я записываю данные на сетевой диск, то :
1)мне в pre-write callback приходят данные без флага IRP_NOCACHE (FlagOn(Data->Iopb->IrpFlags ,IRP_NOCACHE)) : это, как я понимаю говорит мне о том, что запись ведёт менеджер кэша;
2)Data->Iopb->Parameters.Write.MdlAddress = NULL, а Data->Iopb->Parameters.Write.WriteBuffer != NULL при том, что FLTFL_CALLBACK_DATA_SYSTEM_BUFFER флаг не установлен (FlagOn(Data->Flags,FLTFL_CALLBACK_DATA_SYSTEM_BUFFER)) : раньше я такого никогда не видел;
Вот и вопрос — раньше я работал только с данными, которые идут с установленным флагом IRP_NOCACHE и у которых в случае MdlAddress = NULL установлен флаг FLTFL_CALLBACK_DATA_SYSTEM_BUFFER — как поступить теперь и как разобраться во всех этих переплетениях флагов?