Third try to get this posted…
Having recently completed the OSR “Developing File System Drivers For
Windows” course, I was going through and cleaning up a few items I just
learned about. One of those was FastIoQueryOpen.
My filter generally just rejects FastIo calls via FALSE return and forces
them through the IRP path. No problem, except that Explorer can make some
good use of FastIoQueryOpen as I have learned. I re-enabled that code and
found that it isn’t getting past the validity test on the entry point and is
returning FALSE anyway. A quick peek in the debugger reveals that the
FastIoQueryOpen beneath me is, in fact, NULL.
It is the Norton SymEvent filter that is sitting between my filter and NTFS.
SymEvent does clearly claim a NULL entry point for FastIoQueryOpen.
Swapping the load order and placing my filter first wouldn’t help, either,
since there would be no way for that call to get to me through SymEvent.
Am I just SOL on exploiting this single fast path? (It sure would improve
some of the back and forth between Explorer and my filtering operations).
Thanks,
Bill
Peculiar… I suppose there are uncertainties or unwanted behavior with
FastIoQueryOpen path, so Symantec decided to not implement it - why it is NULL, and
not just returning FALSE beats me.
But, this one is not your problem. I suggest doing testing without any filters
first, and any testing with other filters should be compatibility testing solely. You
cannot change behavior of other filters.
Regards, Dejan.
Bill Wilhelm wrote:
Third try to get this posted…
Having recently completed the OSR “Developing File System Drivers For
Windows” course, I was going through and cleaning up a few items I just
learned about. One of those was FastIoQueryOpen.
My filter generally just rejects FastIo calls via FALSE return and forces
them through the IRP path. No problem, except that Explorer can make some
good use of FastIoQueryOpen as I have learned. I re-enabled that code and
found that it isn’t getting past the validity test on the entry point and is
returning FALSE anyway. A quick peek in the debugger reveals that the
FastIoQueryOpen beneath me is, in fact, NULL.
It is the Norton SymEvent filter that is sitting between my filter and NTFS.
SymEvent does clearly claim a NULL entry point for FastIoQueryOpen.
Swapping the load order and placing my filter first wouldn’t help, either,
since there would be no way for that call to get to me through SymEvent.
Am I just SOL on exploiting this single fast path? (It sure would improve
some of the back and forth between Explorer and my filtering operations).
Thanks,
Bill
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.