Доброе время суток! У меня проблема заключается в следующем: я зарегистрировал калбеки: IRP_MJ_OPEN, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_CLOSE и в обработчику IRP_MJ_OPEN проверяю или текущий файл можно открыть для чтения или нет, если да - то добавляю в список указатель на FILE_OBJECT и при IRP_MJ_READ/IRP_MJ_WRITE проверяю этот указатель с FltObjects->FileObject, а при IRP_MJ_CLOSE удаляю указатель с списка. Суть в том что через некоторое время работы заметил что путь к файлу изменился, тоесть в IRP_MJ_READ/IRP_MJ_WRITE сохраненный указатель равен FltObjects->FileObject, но уже отвечает за другой файл. Мой вариант тогда нерабочий. Как можно идентифицировать файл при IRP_MJ_OPEN чтобы потом можно было отловить обращение к нему в IRP_MJ_READ/IRP_MJ_WRITE ? Или надо каждый IRP_MJ_READ/IRP_MJ_WRITE запрос сравнивать имя файлов? Заранее спасибо!
то есть сохранить FileObject->FsContext в PostCreateCallBack и потом проверять его в IRP_MJ_READ/IRP_MJ_WRITE ? он уникален для каждого FileObject-а ?
FsContext уникален для каждого файла, не для FileObject'а, т.е. два FileObject'а будут иметь одинаковый FsContext для одного и того же файла. В свою очередь, для каждого файла может быть создано неограниченное кол-во FileObject'ов.
а когда удалять FsContext с списка? IRP_MJ_CLOSE ? проблема в том что потом (через некоторое время) тот же PFILE_OBJECT указывает уже на другой файл, хотя в IRP_MJ_CLOSE стоит удаление указателя со списка
Ну откуда я знаю? Смотря какая логика у тебя. Если тебе вплоть до закрытия объекта нужно информацию о файле держать, то да. Только не забудь про подсчёт ссылок. Поле FileName в файловых объектах is guaranteed to be valid during pre-create path only. Ну т.е. тебе вообще никто и не обещал, что это поле можно будет использовать после обработки IRP_MJ_CREATE файловой системой. А если имя нужно вплоть до закрытия файлового объекта, тогда его нужно получать отдельно через FltGetFileNameInformation() и класть в свой список рядом с FileObject'ом (точнее рядом с контекстом, разумеется). Внимательно читаем про эту функцию, тут уже был один товарищ, напоролся на косяки с её неправильным использованием.
я делал так - на IRP_MJ_CREATE говорил ObRefereceObject(FileObject) на IRP_MJ_CLOSE/CLEANUP - соответственно Derefrence и адрес FileObject-а поэтому был уникальным, работало нормально
В этом нет смысла, файловый объект до прихода IRP_MJ_CLOSE всё равно никуда не денется. К тому же, за тем, что ты написал, не видно собственно логики, ну т.е. это тоже самое, как если бы ты ничего не написал.
Совершенно верно, т.о. следуя логике z0mailbox, получается, что IRP_MJ_CLOSE не придёт никогда. И что там у него работало - под большим вопросом.
x64 вот видно же что ты с этим на практике не сталкивался на знаешь - лучше промолчи при ренейме внутри тома происходит смена FileObject-а и IRP_MJ_CLOSE придет на другой FileObject а на исходный не прийдет вообще титиретики блин
Непонятно. 1. Что есть смена файлового объекта? Где? Кем? И с какой целью? 2. Почему для файлового объекта не придёт IRP_MJ_CLOSE? Каким образом он будет уничтожен? Что произойдёт при этом? Ну т.е. в этом опять же не видно никакой логики.
при чем тут логика? в реальности приходит в некоторых случаях IRP_MJ_READ/WRITE на FileObject по тому же адресу, но файл там по факту уже совсем другой была такая проблема у меня, в точности то что пишет топикстартер, ресерчилась, лечилась, пофикшено
И в самом деле, зачем нам логика? Так, теперь выясняется что файловый объект всё таки тот же, но... другой. Хорошо, а что у него другое? Грубо говоря, какие из полей структуры FILE_OBJECT у него другие? Давай хотя бы от этого будем плясать. Так ведь никто же не спорит, что при реализации файловых фильтров бывают проблемы. Речь о том, что конкретно в данном случае я пока проблему не вижу. Также речь о том, что ты говоришь некие бессвязные и нелогичные вещи, ты ещё даже не описал симптомов проблемы, о которой говоришь (симптомы автора не в счёт, там проблемы нет).
