I have decided to examine filter samples coming
with Windows 2000 IFS Kit. It seems that I mis-
understand something. I will be very appreciated
if you could explain me issues below.
-
The ERESOURCE object is used in SFILTER sample
for both NT and 2000. But calls to ExAcquireResourceXxx/
ExReleaseResource are placed in between FsRtlEnterFilesystem/
FsRtlExitFilesystem only on 2000 version. (The 2000 DDK
says that normal km APC should be disabled before call to
ExAcquireResourceXxx, but NT DDK does not require this.
Why? Does their behavior really differ on these platforms?)
-
The DDK says that the caller of FsRtlEnterFilesystem/
FsRtlExitFilesystem must be running on PASSIVE IRQL, but
they are used (on 2000) in completion routines, which
potentially could be running on DISPATCH IRQL in arbitrary
TC. The DDK also says that the caller of ExAcquireResourceXxx
must be running on IRQL < DISPATCH, while R. Nagar states in
his book that they can be used on IRQL <= DISPATCH. What is
true?
-
Why do not use IoGetRelatedDeviceObject in
Acquire/ReleaseFileForNtCreateSection fast i/o routines
instead of searching the list of device object’s?
-
The method of handling MOUNT and LOAD_FS requests
used in TFILTER sample differs from one in SFILTER.
Are there special reasons for this or it is just another
way to do the same things?
Thanks in advance,
Leonid.
Leonid,
The FsRtlEnterFileSystem call was inadvertently omitted in the NT 4.0
example and should have been present. In Windows 2000, this error becomes
apparent because the Driver Verifier catches the problem.
It is an error to use FsRtlEnterfileSystem above PASSIVE_LEVEL. In some
file system filter drivers such bugs exist because in most instances the
completion routines are called at PASSIVE_LEVEL. However, this is another
error that driver verifier will find. This problem is resolved in the
Windows XP IFS Kit examples.
IoGetRelatedDeviceObject will not solve the problem - it will only show the
top device on the stack. This works if you have the only (or last) filter
loaded, but suppose you are the middle driver in a stack of drivers.
The SFilter mechanism is the preferred way (note that tfilter has been
replaced by the FileSpy example) but there are many ways to achieve this.
Overall, I’d strongly suggest working with the XP IFS Kit examples rather
than the earlier examples, as a number of critical bugs have been resolved
in the earlier examples.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Hope to see you at the next OSR file systems class October 7, 2002!
-----Original Message-----
From: Leonid Zhigunov [mailto:xxxxx@progate.spb.ru]
Sent: Tuesday, May 07, 2002 9:28 AM
To: File Systems Developers
Subject: [ntfsd] Questions about IFS Kit filter samples
I have decided to examine filter samples coming
with Windows 2000 IFS Kit. It seems that I mis-
understand something. I will be very appreciated
if you could explain me issues below.
-
The ERESOURCE object is used in SFILTER sample
for both NT and 2000. But calls to ExAcquireResourceXxx/
ExReleaseResource are placed in between FsRtlEnterFilesystem/
FsRtlExitFilesystem only on 2000 version. (The 2000 DDK
says that normal km APC should be disabled before call to
ExAcquireResourceXxx, but NT DDK does not require this.
Why? Does their behavior really differ on these platforms?)
-
The DDK says that the caller of FsRtlEnterFilesystem/
FsRtlExitFilesystem must be running on PASSIVE IRQL, but
they are used (on 2000) in completion routines, which
potentially could be running on DISPATCH IRQL in arbitrary
TC. The DDK also says that the caller of ExAcquireResourceXxx
must be running on IRQL < DISPATCH, while R. Nagar states in
his book that they can be used on IRQL <= DISPATCH. What is
true?
-
Why do not use IoGetRelatedDeviceObject in
Acquire/ReleaseFileForNtCreateSection fast i/o routines
instead of searching the list of device object’s?
-
The method of handling MOUNT and LOAD_FS requests
used in TFILTER sample differs from one in SFILTER.
Are there special reasons for this or it is just another
way to do the same things?
Thanks in advance,
Leonid.
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%
Tony,
Thanks for your help.
IoGetRelatedDeviceObject will not solve the problem - it will only show the
top device on the stack. This works if you have the only (or last) filter
loaded, but suppose you are the middle driver in a stack of drivers.
Oh, yes. Of cource. I have forgotten completely about such possibility.
The SFilter mechanism is the preferred way (note that tfilter has been
replaced by the FileSpy example) but there are many ways to achieve this.
The FileSpy example attaches to device by its name, specified in registry.
It does it in reinitialize routine, and if the link is not exist at this
time, it will fail. Even if it will attach successfully, some I/O can
be missed at this time. So, the preferable way is to wait for mount IRP
and attach to newly created logical volume.
The method which is used in TFILTER allow to avoid calls to
FsRtlEnter/Exit
in completion routine. Why it is worse than in SFILTER?
Kind regards,
Leonid.
> 1. The ERESOURCE object is used in SFILTER sample
for both NT and 2000. But calls to ExAcquireResourceXxx/
ExReleaseResource are placed in between FsRtlEnterFilesystem/
FsRtlExitFilesystem only on 2000 version. (The 2000 DDK
Can be a bug in NT4 sample.
must be running on IRQL < DISPATCH, while R. Nagar states in
his book that they can be used on IRQL <= DISPATCH. What is
true?
< DISPATCH for sure.
- Why do not use IoGetRelatedDeviceObject in
Acquire/ReleaseFileForNtCreateSection fast i/o routines
instead of searching the list of device object’s?
Because your filter can be not the topmost filter.
Max