Всем привет!
Задача вследующем: Есть файл. Он содержит какие-то данные. Есть куча задач, открываюших его. Требуется «каждая задача должна видеть содержимое этого файла “по-своему”»

Легко, скажете Вы! (правда может и не скажите…) Берем, перехватываем CreateFile(+DublicateHandle), составляем список из процессов и handle-ов открываемых файлов. Перехватываем ReadFile, читаем данные, изменяем их как-то – и всё. Готово!
А вот как быть, если кому-то вздумалось не делать ReadFile, а пользовать CreateFileMapping/MapViewOfFile??? Можно, конечно, Вместо ф-ии MapViewOfFile выполнить чтение файла, зармешение в user-адр. пр-ве и передать BaseAddress. Пусть мол думает, что это проекция… а это просто мёртвый блок данных. Но этот метод неустойчив и требует перехвата кучи ф-й, связанных с SectionObject. На нем мы останавливаться небудем.

Теперь главное. К сути… процесс проецирования в кратции:
Сначала открывается файл, затем передается хэндл в CreateFileMapping после нудных проверок создается объект «секция», потом вызавается последняя для этой стадии MiCreateDataFileMap, которая разбивает файл по частям, в соответствии с PTEs и заполняет поля в объекте Section. При вызове MapViewOfFile насколько я понимаю, в основном, производится уже на самом деле вписка новых PTEs в соответствии с параметрами процесса.
Так вот, что меня очень! Очень! Волнует: в этом и загвоздка: где, кто и на коком этапе производится чтение из файла и запись в него обратно из проекции. Что это за менеджер и где его достать…

P.S. Большое предисловие – это чтобы было понятнее про чё я тут толкую. Не придираться к отсутствию суффиксов Ex и т.д. у ф-й – это не принципиально.

С нетерпением жду ответов, предложений, вопросов, ссылок и т.д. короче, буду рад всему.

для записи вот похоже IoSynchronousPageWrite, а вот для чтения кто??? И кто их вообще вызывает.

Заранее _очень_ благодарен --==PPS==--

Так вот и для чтения и для записи соотв-но:
IoPageRead(
IN PFILE_OBJECT FileObject,
IN PMDL MemoryDescriptorList,
IN PLARGE_INTEGER StartingOffset,
IN PKEVENT Event,
OUT PIO_STATUS_BLOCK IoStatusBlock
)
IoSynchronousPageWrite(
IN PFILE_OBJECT FileObject,
IN PMDL MemoryDescriptorList,
IN PLARGE_INTEGER StartingOffset,
IN PKEVENT Event,
OUT PIO_STATUS_BLOCK IoStatusBlock
)
или
IoAsynchronousPageWrite(
IN PFILE_OBJECT FileObject,
IN PMDL MemoryDescriptorList,
IN PLARGE_INTEGER StartingOffset,
IN PIO_APC_ROUTINE ApcRoutine,
IN PVOID ApcContext,
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PIRP *Irp OPTIONAL
)
они должны вызываться приработе файловыми отображениями.

Тогда другой вопрос: а есть ли вообше этот менеджер, который ч/з некоторое время обновляет страницы файлового отображения из файла и сбрасывает их туда. И, например, делает это по тику таймера или когда еще...???

Вроде бы MMF висят в физической памяти, а процессы имеют ссылку на эту область. Таким образом никакого менеджера нет, просто когда процесс меняет MMF, он меняется в физической памяти. Поэтому остальные процессы сразу видят все изменения.

По-моему это логично, хотя никакими фактами и ссылкой на источник поделиться не могу, т.к. это просто мои мысли по поводу MMF.

MMF - Memory Mapped File (чтобы не было недопонимания)

"MMF - Memory Mapped File (чтобы не было недопонимания)" :-)
Имеется ввиду менеджер, который со временем дампит DirtyPages - в исходный файл, вызывая ф-ю ??FlushSection. Или соотв-но, кторый читает в секцию (объект, описывающий эту проекцию) данные из файла. На сколько мне известно первое чтение производится при вызове MapViewOfFile->MapViewOfDataSection. А потом чёрт его знает. И неизвесто как поведет себя проекция в памяти при изменении содержимого файла ч/з ReadFile. Или например это: Известно, что MMF очень хороши, при боьших размерах файлов. Значит, если правильно понимать, проецируется не фесь файл, зато вот PEBs заполняются полностью, а далее при попадании на тот адрес, где должен быть спроцирован файл, но система его пока туда не прочитала, вызавается(-:)) PageFault, который ч/з IoReadPage читает в страницу данные из проецируемого файла.
Можно, конечно, заьить на всё и перехватить IoReadPage и просто смотреть на FileObject, но какиииие будут тормоза, ведь при каждом PageFault это будет вызаваться. А частота вызова PageFault известно всем... 8-)

Короче куча неизвестностей.... heeeelp!

Привет!

Условия задачи неполные, поэтому напишу как я это понимаю.

Пишется драйвер, который следит за открытием файлов. Если открывается тот самый файл, то драйвер:
1. Получает директорию старта программы, запрашивающей тот самый файл на открытие.
2. Генерит некое имя нового файла, которое не существует в данной директории.
3. Копирует оригинальный файл в новый.
4. Открывает его и возвращает хендл в приложение.

Поправлю: В файле есть посл-ть "1-2-3-4-5"
Файл №1 видет это как 2-3-4-5-6 файл №2 как 0-1-2-3-4 и т.д. т.е я создаю список файлов и создаю пространство отобрадений данных из этого файла для каждого процесса. Вопрос Как проследить за чтением данных /или как заставить процессы (хрен знает как ини будут получать инфу из файла) видеть то, что я хочу..... Вот ...вроде...

PavPS
А можно ли отслеживать работу с объектом(file) как токавым.Т.е. следить за работой системы с файловой системой и выкупать когда работа в файл системе идет именно с нашим объектом.отсюда получается проблема привязки к объекту.как выкупить что именно с нашим объектом

Я бы рад следить за драйвером файловой системы, точнее за device-ом. Эта фихня указана в структуре FILE_OBJECT, только вот неплохо бы иметь его основные IO-коды и т.п. Хотя можно сесть на хвост CallDriver. Посмотрим, посмотрим...

Почему бы тебе не забить на ReadFile/CreateFileMapping?
Перехватывай только CreateFile, и подменяй пути к файлу, чтобы открывались каждый раз нужные файлы...

Ага! Подменяй... один файл 780 метром, а другая _группа_ файлов 1,2 гига??? чё свои дубликаты этих файлов создавать. Погонят меня поганой метлой за такое... :-(