> In the work item calling the FltCreateFile function so as it goes again to
the create callback to perform the operation .
It shouldn’t, unless you specify NULL as the Instance (second parameter to
FltCreateFileEx2). Thats the whole point of FltCreateFile as opposed to
IoCreateFile, you can make sure it only goes to lower filter.
Yes, i am passing NULL so as it goes again from the top of the stack. And by the worker thread i want to perform the deferred operation again on the same file.
Any suggestion plz?
Below is the query:
In my create call back I am performing an operation on a file, if that get times out I do a deferred operation on the same file on a work item using FltQueueGenericWorkItem api. Not waiting for the thread to complete.
In the work item calling the FltCreateFile function so as it goes again to the create callback to perform the operation . To identify whether the request is from the same file on which I want to perform the deferred operation I am using a global queue that keeps the file name and a flag.
When I am accessing the file (an exe) from cmd application, the first request get times out and I initiate the deferred operation expecting my work item to perform the request however at the same time again the request comes from the cmd application and on that deferred operation is performed.
Can anyone please suggest how can I differentiate between the workitem thread request and the CMD (*second*) request so as my work item thread only server the request.
> Yes, i am passing NULL so as it goes again from the top of the stack.
Why do you think you need to do this? Why not just send the create down to
the lower layers?
There are many ways of detecting re-entrancy, the easiest involves just
keeping track of which thread is doing what, but why detect something you
can avoid?