Wierd FastIoQueryOpen behavior related to STATUS_REPARSE

NTFSD
1

Hi

In my FSFD, I am modifying the IRP_MJ_CREATE call to return STATUS_REPARSE
so that file open / create requests are redirected to a new file. This is
working fine.

I now have an issue with the case where an application calls LoadLibrary,
specifying a DLL that has a hard coded path. This is resolving to a
FastIoQueryOpen call, in which I am returning FALSE to cause the IO manager
to use the IRP_MJ_CREATE. Reading the NTFSD archives, this seems like the
correct path to follow. I am returning FALSE for all calls to
FastIoQueryOpen for the process in question.

The problem is that by returning FALSE from my hook routine I never see the
call later as an IRP_MJ_CREATE, the LoadLibrary call fails when searching
for the DLL.

I have tried a number of various combinations in FastIoQueryOpen, including
returning FALSE and TRUE, and setting Irp->IoStatus.Status = STATUS_SUCCESS,
all with no joy.

The system is Win2k. No virus scanners etc are running. Is the approach
that I am taking valid on Win2k? Am I missing something?

Any help or nuggets of information would be very appreciated.

Thanks
Lee

[Views expressed are not those of Citrix]

2

Wierd FastIoQueryOpen behavior related to STATUS_REPARSEIf you attach sfilter from IFS kit to a FAT volume sfilter will behave exactly as your filter with regards to FastIoQueryOpen.
You may try to run your application on FAT + sfilter to see what sequence of requests is generated. As far as I know returning FALSE from FastIoQUeryOpen should always generate sequence of IRPs starting with IRP_MJ_CREATE, it is the only way for a FSFD to handle FastIoQUeryOpen if underlying FS doesn’t support this call.

Alexei.

“Lee Laborczfalvi (AU)” wrote in message news:xxxxx@ntfsd…
Hi

In my FSFD, I am modifying the IRP_MJ_CREATE call to return STATUS_REPARSE so that file open / create requests are redirected to a new file. This is working fine.

I now have an issue with the case where an application calls LoadLibrary, specifying a DLL that has a hard coded path. This is resolving to a FastIoQueryOpen call, in which I am returning FALSE to cause the IO manager to use the IRP_MJ_CREATE. Reading the NTFSD archives, this seems like the correct path to follow. I am returning FALSE for all calls to FastIoQueryOpen for the process in question.

The problem is that by returning FALSE from my hook routine I never see the call later as an IRP_MJ_CREATE, the LoadLibrary call fails when searching for the DLL.

I have tried a number of various combinations in FastIoQueryOpen, including returning FALSE and TRUE, and setting Irp->IoStatus.Status = STATUS_SUCCESS, all with no joy.

The system is Win2k. No virus scanners etc are running. Is the approach that I am taking valid on Win2k? Am I missing something?

Any help or nuggets of information would be very appreciated.

Thanks

Lee

[Views expressed are not those of Citrix]