(log)-> Delete File by minifilter Driver

[Scoot3r]

Hi,
i read "Delete_File" Sample code by microsoft
And I have a some issue
what is mean in-flight change ?(I still do not understand )

microsoft/Windows-driver-samples

// Race detection logic. The NumOps field in the StreamContext
// counts the number of in-flight changes to delete disposition
// on the stream.
//
// If there's already some operations in flight, don't bother
// doing postop. Since there will be no postop, this value won't
// be decremented, staying forever 2 or more, which is one of
// the conditions for checking deletion at post-cleanup.
//

race = (InterlockedIncrement(&streamContext->NumOps) > 1);

if (!race) {

//
// This is the only operation in flight, so do a postop on
// it because the final outcome of the delete disposition
// state of the stream is deterministic.
//

*CompletionContext = (PVOID)streamContext;

return FLT_PREOP_SYNCHRONIZE;

 

[x BlueRobot]

I don't know much about the Filter Manager, however, I believe that "in-flight" is referring to the I/O request and it's corresponding operation. For example, if someone has already sent a file delete request, and the file is in the process of being deleted, then the operation is said to be "in-flight". That's my understanding anyway.

 

[x BlueRobot]

Just found some more information:

So once a minifilter instance attaches to a volume it will start receiving IRPs and the filter will process them. There are many cases where filters need to process the results of the operation after the file system has completed it so the filter would register PostOperation callbacks and the filter would return an appropriate status to indicate that it wants a that PostOp callback called for each specific operation. These IRPs are generally called in-flight requests and in many cases the filter has data allocated associated with the operation (buffers allocated and possibly even replaced on the request, contexts that are sent from the PreOp callback to the PostOp callback, references (if the filter references a context in PreOp and dereferences it in PostOp) and so on). In case the instance needs to be detached (the minifilter is unloaded or just one instance is detached from the underlying volume) from a live volume, IO will continue to flow on the volume. One way to detach is to stop receiving new IO requests and then just wait for all the in-flight operations to be completed by the file system. Once all the in-flight operations have completed then FltMgr can pretty much free the instance because there can not be any more IO on it.

Source: Detaching Instances and FLTFL_POST_OPERATION_DRAINING

 

[Scoot3r]

Thank you
your awesome