I checked the forum threads and noticed several code samples for someone’s filter driver for a reparse points scenario. It looks like in every sample that the filter is the one that completes the IRP. Does this mean that the actual file system never saw the IRP? Or does it mean that the file system did get the IRP, but simply returned STATUS_REPARSE and did not complete the IRP(rather, the filter completed it).
Basically, I’m looking for some guidance on the interaction between a filter and an file system(FSD) for a reparse scenario when it comes to completing the [create] IRP. When is a filter responsible for completing the IRP(as I noticed in all the code samples) and when is it the FSD’s job?
The answer depends on what the reparse point is used for. If you are writing a filter that uses a reparse point you need to either complete the request or send it back down with FILE_OPEN_REPARSE_POINT so it gets opened by the file system. Typically you would do some processing before sending it back down, like validating the reparse data and maybe changing the path or checking the create options and failing anything you do not want to allow. Something like this:
if (Data->IoStatus.Status == STATUS_REPARSE)
{
if (Data->TagData->FileTag == your_tag)
{
// Do your processing here
// Then complete it or send it back as shown here…
Data->Iopb->Parameters.Create.Options |= FILE_OPEN_REPARSE_POINT;
FltSetCallbackDataDirty(Data);
FltReissueSynchronousIo(FltObjects->Instance, Data);
…
Once you reissue the create you can check if it was successful and add context so you can do more processing on reads/writes, etc.