I have a mini-filter driver that talks to an external application. When the filter driver receives IRP_MJ_CLEANUP, it sends a message to the application which then grabs the file off of disk and makes a copy. This technique works most of the time when I drag&drop a directory or set of files to another directory, however on slower systems I see access denied for few files. I believe that is because of lazy-write.
My question is:
How can I avoid access denied?
Should I be creating a copy through the driver either in a separate thread or inside the IRP_MJ_CLEANUP? (this probably will slow down the system)
If I should do it through driver then how can I avoid a recursion i.e. If I call FltReadFile() from with in driver then will it again generate IRP_MJ_CREATE/WRITE/CLEANUP etc. For my application I avoid processing this IRP by checking if the create request was originated by my external application. If yes then igore it. Is there a similar way to check if this request was originated by my driver.
When exactly do you perform a copy and when you dont?
I always created a file copy in post-IRP_MJ_CREATE callbacks (and then all
read/write/set_information/… IRPs were forwarded to new FileObject). I’d
say, you may perform a copy in pre-IRP_MJ_CLEANUP callback (at
PASSIVE_LEVEL), because the file is still opened - so copy the file in
kernel-mode. User-mode API fn “CopyFile” opens the source file
(irp_mj_create), reads its content (irp_mj_read) and writes it to the new
target file.
pre-IRP_MJ_CLEANUP routine must be at passive_level, which is not called –
so save the FileObject, return SUCCESS (don’t call completion routine) and
perform IO operations later from a thread – then close the file.
If I should do it through driver then how can I avoid a recursion i.e.
If I call FltReadFile() from with in driver then will it again generate
IRP_MJ_CREATE/WRITE/CLEANUP etc
Flt* functions are not recursive
-Petr
wrote in message news:xxxxx@ntfsd… > Hello Folks, > > I have a mini-filter driver that talks to an external application. When > the filter driver receives IRP_MJ_CLEANUP, it sends a message to the > application which then grabs the file off of disk and makes a copy. This > technique works most of the time when I drag&drop a directory or set of > files to another directory, however on slower systems I see access denied > for few files. I believe that is because of lazy-write. > My question is: > 1. How can I avoid access denied? > 2. Should I be creating a copy through the driver either in a separate > thread or inside the IRP_MJ_CLEANUP? (this probably will slow down the > system) > 3. If I should do it through driver then how can I avoid a recursion i.e. > If I call FltReadFile() from with in driver then will it again generate > IRP_MJ_CREATE/WRITE/CLEANUP etc. For my application I avoid processing > this IRP by checking if the create request was originated by my external > application. If yes then igore it. Is there a similar way to check if this > request was originated by my driver. > > Any help is much appreciated. > > Thanks. >
The copies are always created if the file operations are not originated from my external app and they are created by the external app when I send it a message through pre-IRP_MJ_CLEANUP callback.
When you say don’t call completion routine, you mean return FLT_PREOP_PENDING and then queue the io using FltQueueDeferredIoWorkItem() and then later call FltCompletePendedPreOperation() from the worker thread? Sorry I am new to these things…It will be really great if you provide a little more specifics.