Я думаю некоторые помнят проект he4dev.
xttp://he4dev.e1.bmstu.ru, на главной странице,
описывается механизм перенаправления операций с файлами.
Оценивать его стабильность не стоит, интересует более стабильный,
более документированный способ. Перехват функций ntoskrnl предлагать не стоит.
Большая просьба поделиться информацией.

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

R>Я думаю некоторые помнят проект he4dev.
R>xttp://he4dev.e1.bmstu.ru, на главной странице,
R>описывается механизм перенаправления операций с файлами.
R>Оценивать его стабильность не стоит, интересует более стабильный,
R>более документированный способ. Перехват функций ntoskrnl предлагать не стоит.
R>Большая просьба поделиться информацией.

Фильтр-драйвер файловой системы. В WDK есть примеры.

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

ON>Фильтр-драйвер файловой системы. В WDK есть примеры.

Я так понимаю, вы хорошо разбираетесь в вопросе.
Вы подразумеваете под примерами, filespy и sfilter?
Возможностей для перенаправления я не увидел там, может не понял, может что другое. Поясните, что нужно делать в общем случае, например
кто-то открывает и пишет в файл c:\readme.txt, как же сделать так, что-бы
процесс в контексте которого это происходит, обращался к d:\resdme.txt?

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

R>Здравствуйте, Old Nick, Вы писали:

ON>>Фильтр-драйвер файловой системы. В WDK есть примеры.

R>Я так понимаю, вы хорошо разбираетесь в вопросе.
R>Вы подразумеваете под примерами, filespy и sfilter?
R>Возможностей для перенаправления я не увидел там, может не понял, может что другое. Поясните, что нужно делать в общем случае, например
R>кто-то открывает и пишет в файл c:\readme.txt, как же сделать так, что-бы
R>процесс в контексте которого это происходит, обращался к d:\resdme.txt?

Поменять имя в Irpе:
IrpSp = IoGetCurrentIrpStackLocation(Irp);
IrpSp->FileObject->FileName = NewFileName;
IrpSp->FileObject->RelatedFileObject = NULL;

ON>Поменять имя в Irpе:
ON>IrpSp = IoGetCurrentIrpStackLocation(Irp);
ON>IrpSp->FileObject->FileName = NewFileName;
ON>IrpSp->FileObject->RelatedFileObject = NULL;

Да, но придется во многих обработчиках это делать?
Т.е. можно ставить фильтр на устройство харддискволуметакой-то
и при MJ_CREATE например так делаем? Есть же еще fastio, фаловых фильтров я не писал ранее, поэтому есть сомнения, что все так просто

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

ON>>Поменять имя в Irpе:
ON>>IrpSp = IoGetCurrentIrpStackLocation(Irp);
ON>>IrpSp->FileObject->FileName = NewFileName;
ON>>IrpSp->FileObject->RelatedFileObject = NULL;

R>Да, но придется во многих обработчиках это делать?

Вы вернете хендл на файл и далее пользователь будет работать с этим хендлом.
Так что не во многих...

R>Т.е. можно ставить фильтр на устройство харддискволуметакой-то
R>и при MJ_CREATE например так делаем? Есть же еще fastio, фаловых фильтров я не писал ранее, поэтому есть сомнения, что все так просто

FastIo на открытие можно убрать.
Возвращайте FALSE в FastIoQueryOpen.

В качестве примера рекомендую взять sfilter.
Он практически представляет из себя болванку для написания фильтр-драйвера файловой системы.
Небольшое количество кода по измерению производительности легко из него изымается.

Некоторые проблемы будут с определение имени файла, который пользователь хочет открыть.
IrpSp->FileObject->FileName не всегда содержит полный путь...

Но все действительно не так просто как хотелось бы...
Просто все станет тогда, когда Вы все напишите и отладите

Если Вас интересуют файловые системы, то есть книжка:
Rajeev Nagar "File System Internals"
Найти ее в инете не очень просто, но реально (я смог .

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

ON>В качестве примера рекомендую взять sfilter.
ON>Он практически представляет из себя болванку для написания фильтр-драйвера файловой системы.
ON>Небольшое количество кода по измерению производительности легко из него изымается.

а почему не filespy? sfilter вроде динамически не умеет определять свежесмоттированные диски?

А есть ли еще какие-то подводные камни?

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

R>Здравствуйте, Old Nick, Вы писали:

ON>>В качестве примера рекомендую взять sfilter.
ON>>Он практически представляет из себя болванку для написания фильтр-драйвера файловой системы.
ON>>Небольшое количество кода по измерению производительности легко из него изымается.

R>а почему не filespy? sfilter вроде динамически не умеет определять свежесмоттированные диски?
Умеет.

Уже не помню, почему он мне не понравился, но, sfilter, кажется, проще.

R>А есть ли еще какие-то подводные камни?
Наверняка, есть

R>>А есть ли еще какие-то подводные камни?
ON>Наверняка, есть

Книжко уже ест. спасибо вам за содержательные ответы. Ждем ответов от остальных участников.

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

R>описывается механизм перенаправления операций с файлами.
R>Оценивать его стабильность не стоит, интересует более стабильный,
R>более документированный способ. Перехват функций ntoskrnl предлагать не стоит.
такой механизм уже реализован — есть такая фича IO Manager как reparse points, используется для реализации NTFS junction points & hard links и много еще где.

есть вводная — статья на OSR: Play It Again, Sam -- Reparse Points in Windows

еще поищите по форуму?

а вот, кстати, не так давно обсуждалось — про виртуальные файлы, Re[4]: Замена файла в чужом процессе.

Автор: Valery A. Boronin
Дата: 23.05.07

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>И здесь при попытке открытия заведомо известного файла вы подменяете его путь в недоконструированном FileObject (обязательно чтобы файл-заместитель лежал на том-же логическом разделе). После такого "мошенничества" IRP пакет приходит в обработчик IRP_MJ_CREATE драйвера ФС и далее обрабатывается, но уже вовсе для другого файла.

А почему он должен лежать на том же логическом диске? Откуда это выплывает?

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

[skip]

VAB>>И здесь при попытке открытия заведомо известного файла вы подменяете его путь в недоконструированном FileObject (обязательно чтобы файл-заместитель лежал на том-же логическом разделе). После такого "мошенничества" IRP пакет приходит в обработчик IRP_MJ_CREATE драйвера ФС и далее обрабатывается, но уже вовсе для другого файла.

R>А почему он должен лежать на том же логическом диске? Откуда это выплывает?

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

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

З>Это выплывает, из того что парсер уже определил, какой стек файловой системы используется и послал запрос, а вы его получили.

Парсер это OBJECT_TYPE->ParseProcedure которая?

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

R>Здравствуйте, Злость, Вы писали:

З>>Это выплывает, из того что парсер уже определил, какой стек файловой системы используется и послал запрос, а вы его получили.

R>Парсер это OBJECT_TYPE->ParseProcedure которая?

Нет, есть общий для всех "граматический" разборщик IopParseDevic, в кавычках потому что он выполняет намного больше.

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

З>Нет, есть общий для всех "граматический" разборщик IopParseDevic, в кавычках потому что он выполняет намного больше.

http://www.i.u-tokyo.ac.jp/edu/training/ss/msprojects/data/04-ObjectManagerLPC.pdf
http://www.ntkernel.com/forum/viewtopic.php?t=169&view=next&sid=c5a26064e4f587668f0311a024a41482

все же это она? или я что-то путаю? или же вы не точн овыразились?

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

[skip]

З>>Нет, есть общий для всех "граматический" разборщик IopParseDevic, в кавычках потому что он выполняет намного больше.

R>http://www.i.u-tokyo.ac.jp/edu/training/ss/msprojects/data/04-ObjectManagerLPC.pdf
R>http://www.ntkernel.com/forum/viewtopic.php?t=169&view=next&sid=c5a26064e4f587668f0311a024a41482

R>все же это она? или я что-то путаю? или же вы не точн овыразились?

Это она, для типа обьекта — device, будет вызвана при начале парсинга имени из ObOpenObjectByName.