xxxxx@gmail.com wrote:
Thanks Matt for comments.
Yes that what i understood. If i will pad the data then it will definitely change the file size and add more complications.
Can we associate paging IO with regular IO? If I can find out that this paging IO/IOs were result of this regular IO then i can track the actual length from regular IO. I am already tracking all the open files on the system with small structure for other reasons and used file context in filter manager. I was wondering if i can track the “Actual Data Size” (which is the length) and offset in the regular IO and then somehow use them in the paging IO. But if the data is more than a page (more than 4K) then i am not sure if the paging IOs will issued in the order. If no then i wouldn’t know weather the first Paging IO has 4k of actual data or the second one. 
You can not directly associate a given cached/non cached IO with a
paging IO since multiple processes could be modifying a file within the
same range and you would only see a single set of paging IO requests.
What you can do, and this does get quite complicated, is track the
non-paging IO requests and modify the file size to accommodate your
padding at that time. This requires extending the file correctly during
file extending writes in the non-paging path. This will allow you to
have the correct file sizes during the paging IO processing. You also
need to deal with the cases of extension and truncation through the
SetFileInfo calls.
We have implemented many data modification filter drivers and getting
this right takes a lot of forethought and testing.
Also, Rod mentioned about the “Shadow Copy” approach, Does he mean make a shadow copy and use that device object to find out the file size. Like we have been using the shadow copies for reading/writing to the files to avoid loop back.
Rod is referring to actually having a separate file that contains the
modified data and the actual sizes and then having your file exposed to
the upper callers be a ‘stub’ file of the correct size, etc. Then you
redirect IO requests accordingly to the shadow file. Again, this is not
a huge step in making things less complicated, just shifting it around.
You will basically need a lyered file system in this approach to manage
the shadow files.
Also, does filter manager help in resolving this issue somehow?
No, filter manager does not make things easier in this regard.
Pete
I understand its getting complicated. well i am certain my company will not spend the money to talk to OSR
I wish i can do that as well.
I know these are tons of questions and i really appreciate everyone for quick response and all the help.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295