Работа с сетевым диском из ядра
От: Аноним  
Дата: 06.12.12 10:27
Оценка:
Всем привет!
Появился такой вопрос — можно ли из минифильтра, который аттачится к сетевому редиректору (LanmanRedirector),получить тип диска (Removable или Fixed)? Или вообще никак нельзя такое предпринять? Как тогда система распознаёт истинную файловую систему удалённого устройства и его размер?
Re: Работа с сетевым диском из ядра
От: Аноним  
Дата: 07.12.12 20:29
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Всем привет!

А>Появился такой вопрос — можно ли из минифильтра, который аттачится к сетевому редиректору (LanmanRedirector),получить тип диска (Removable или Fixed)? Или вообще никак нельзя такое предпринять? Как тогда система распознаёт истинную файловую систему удалённого устройства и его размер?

Никто не подскажет? Может быть господин x64 поможет?
Re[2]: Работа с сетевым диском из ядра
От: x64 Россия http://x64blog.name
Дата: 08.12.12 12:27
Оценка:
А>Может быть господин 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 протокол?
Re[4]: Работа с сетевым диском из ядра
От: x64 Россия http://x64blog.name
Дата: 08.12.12 18:59
Оценка:
А>...но ничего не получилось...

Какой бестолковый раб попался.
Как именно пробовал и что именно "не получилось"?

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


Да, без всяких "либо".

А>...либо объекту в 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) не передаётся на серверную часть?
Re[6]: Работа с сетевым диском из ядра
От: x64 Россия http://x64blog.name
Дата: 08.12.12 21:44
Оценка:
А>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,спасибо тебе большое за помощь!
Интересно было бы узнать каким бы образом ты решал бы эту проблему — через перехват сетевого трафика или минифильтром файловой системы?
Re[8]: Работа с сетевым диском из ядра
От: x64 Россия http://x64blog.name
Дата: 11.12.12 14:10
Оценка:
А>Интересно было бы узнать каким бы образом ты решал бы эту проблему...

Какую именно проблему?
JID: x64j@jabber.ru
Re[9]: Работа с сетевым диском из ядра
От: Аноним  
Дата: 11.12.12 15:04
Оценка:
x64>Какую именно проблему?

Проблему перехвата данных, которые передаются на сетевой диск.
Re[10]: Работа с сетевым диском из ядра
От: x64 Россия http://x64blog.name
Дата: 11.12.12 15:29
Оценка:
А>Проблему перехвата данных, которые передаются на сетевой диск.

Ну давай, давай, ещё более общие слова придумай, останешься вообще без помощи.
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 — как поступить теперь и как разобраться во всех этих переплетениях флагов?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.