tracking changes made to a file

I’m writing a minifilter driver for the purpose of tracking changes made to files.

What I have tried to do is:

I’ve registered for IRP_MJ_WRITE and trying to read the file content in pre-operation callback and post-operation callback. There are two main problems:

  1. I’m reading the content of the file with FltReadFile(), and if I’m not mistaken nothing promises me that the function will not cause a pagefault. Since the pre\post-operation callback runs in DPC I have a good chance of getting a BSOD.
  2. Even if I’ll not get a blue screen the above will likely cause very significant penalty to the performance of the system.

Can anyone suggest me a way to deal with the above problems?

Your pre-write handled better not be called at DISPATCH though
post-write may be called at DISPATCH. You can perform a read, ensuring
you are correctly doing the cached/non-cached/paging, etc. within your
FltReadFile() call but yes, it will incur an overhead. You are
converting 1 IO into 2 if you only do the read in pre-write. For
post-write you can return SYNCHRONIZE to ensure your completion is not
called at DISPATCH. But if you perform a read in pre-write and you know
the content of the write buffer, then what do you need to read in
post-write?

Pete

Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: “xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 11/21/2017 5:16:12 AM
Subject: [ntfsd] tracking changes made to a file

>I’m writing a minifilter driver for the purpose of tracking changes
>made to files.
>
>What I have tried to do is:
>
>I’ve registered for IRP_MJ_WRITE and trying to read the file content in
>pre-operation callback and post-operation callback. There are two main
>problems:
>1. I’m reading the content of the file with FltReadFile(), and if I’m
>not mistaken nothing promises me that the function will not cause a
>pagefault. Since the pre\post-operation callback runs in DPC I have a
>good chance of getting a BSOD.
>2. Even if I’ll not get a blue screen the above will likely cause very
>significant penalty to the performance of the system.
>
>Can anyone suggest me a way to deal with the above problems?
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

On your IRP_MJ_WRITE, change the IRP to IRP_MJ_READ and set a completion
handler. In that completion handler, change the IRP_MJ_READ back to an
IRP_MJ_WRITE and send it down again. Tweaking your buffers as you need on
the way down (i.e. swap out write buffer with new read buffer, and then
swap back in the write buffer). This is about as fast as you can get. You
can compare the the two buffers to see if anything actually changed.
Windows will do lots of writes of data that does not change. One
optimization is that if the data does not change (compare read buffer to
write buffer in read completion handler), you can skip the write all
together for added performance. I’ve used this trick in a volume filter to
reduce writes to SSD; at a small performance penalty.

On Tue, Nov 21, 2017 at 2:50 PM PScott <
xxxxx@lists.osr.com> wrote:

>
> Your pre-write handled better not be called at DISPATCH though
> post-write may be called at DISPATCH. You can perform a read, ensuring
> you are correctly doing the cached/non-cached/paging, etc. within your
> FltReadFile() call but yes, it will incur an overhead. You are
> converting 1 IO into 2 if you only do the read in pre-write. For
> post-write you can return SYNCHRONIZE to ensure your completion is not
> called at DISPATCH. But if you perform a read in pre-write and you know
> the content of the write buffer, then what do you need to read in
> post-write?
>
> Pete
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295 <(866)%20263-9295>
>
> ------ Original Message ------
> From: “xxxxx@gmail.com
> To: “Windows File Systems Devs Interest List”
> Sent: 11/21/2017 5:16:12 AM
> Subject: [ntfsd] tracking changes made to a file
>
> >I’m writing a minifilter driver for the purpose of tracking changes
> >made to files.
> >
> >What I have tried to do is:
> >
> >I’ve registered for IRP_MJ_WRITE and trying to read the file content in
> >pre-operation callback and post-operation callback. There are two main
> >problems:
> >1. I’m reading the content of the file with FltReadFile(), and if I’m
> >not mistaken nothing promises me that the function will not cause a
> >pagefault. Since the pre\post-operation callback runs in DPC I have a
> >good chance of getting a BSOD.
> >2. Even if I’ll not get a blue screen the above will likely cause very
> >significant penalty to the performance of the system.
> >
> >Can anyone suggest me a way to deal with the above problems?
> >
> >
> >—
> >NTFSD is sponsored by OSR
> >
> >
> >MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> >software drivers!
> >Details at http:
> >
> >To unsubscribe, visit the List Server section of OSR Online at
> >http:
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></http:>