Minifilter, replacing the name in FileObject when IRP_MJ_CREATE with FILE_OPEN_BY_FILE_ID

Hello everybody!
In my minifilter, when IRP_MJ_CREATE comes with the FILE_OPEN_BY_FILE_ID flag, I change the ID that is in Data->App - >TargetFileObject - >FileName to the ID of another file

I get the ID and replace the ID as follows:

FILE_ID_INFORMATION fileID;
...

status = FltQueryInformationFile(
    FltObjects->Instance,
    foReplacingFile,
    &fileID,
    sizeof(fileID),
    FileIdInformation ,
    NULL);
...
status = IoReplaceFileObjectName(FltObjects->FileObject, (PWCHAR)&fileID.File Id, sizeof(fileID.File Id));

Returning STATUS_REPARSE

Data->IoStatus.Information = IO_REPARSE;
Data->IoStatus.Status = STATUS_REPARSE;

In this case, the repeated irp does not come. In User Space, I get the error " ERROR_INVALID_NAME"


I tried to replace it with a name of the following type:
??\Volume{e148406e-0000-0000-0000-402400000000}<< FILE_ID >>

In this case, the irp comes again, the mini filter works without errors, but the User Space still has an error

At the same time, in the kernel, I can open a file using this ID

Has anyone run into a problem where there might be a bug?

You’d be surprised at how many issues reparsing can cause. Even MS’s SymRep sample will fault in many Driver Verifier → FltMgr checks (well, not the vanilla one, because it only checks a few simple files that are not used in any complicated way, but if you extend it a bit more files, it does).

When you return REPARSE you have to include the volume in the file name. The IO manager does not know that you want to reparse to the same volume :slight_smile:

What I found to be actually work a lot better is to change the file name, and just pass down the create. This is also a lot faster, since the upper filters and IoMgr will not need to process the same open.

I do not see any issue in your second approach, though. The only difference, from what I did during testing, was to use a nonpersistent device name, instead of a GUID based one, but that should not matter (e.g. \device\harddiskvolume2<FileID>).

Are you sure the create succeeds? Seems like an obvious question, but often comes down to such.
Is the status in your post-create a success code, when the new fileID call returns from the lower filters?

1 Like

Yes, thank you
In my post callback, I open with the parameters specified in Data->iopb, but ntdevice name
After fixing it, the version with volume id is now working