RE: assuming process context in a filter driver - what ar-e the rules?

Joel,

Don’t be TOO paranoid here. Ask yourself if this would work with an
ordinary file system. If the answer is “no” then a file system filter
driver that behaved this way would break the file system - not to mention
your filter driver.

Thus the safest assumption becomes: as a file system filter driver, you can
assume you will be called in process context if the underlying file system
assumes that IT will be called in process context.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:

-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, May 31, 2000 3:06 PM
To: File Systems Developers
Subject: [ntfsd] assuming process context in a filter driver - what are the
rules?

Hello,
I’m wondering if it is wrong to assume process context in a filter
driver. For example, say I need to build a fully qualifed path for the
destination file name during a rename operation. This means I may have to
contend with the FILE_RENAME_INFORMATION.RootDir (in order to figure out
what the rest of the dest name is relative to). So, as long as I am getting
called in the same context as the originator of the io request (the normal
case), this should be relatively easy (just reference the object by handle
to get the file object and then use the file object to get to the name).

However, suppose some filter driver above me decides to pend this
IRP_MJ_SET_INFORMATION request and process it in the system process for some
reason and then passes it down to the lower level driver (me). Now I cannot
reference the handle and cannot as easily get the file name because I am not
in the expected context.

So, what are the rules here? As a file system filter, is it wrong
to assume that I will be called in the context of the originator of the io
request because someone above me may have pended the IRP? Or, is it wrong
for a filter driver to hand an IRP off for background processing and then
pass it down to lower level drivers from an unexpected process context?

Thanks,
Joel</http:>