Rob,
In general, it is NEVER safe to assume that any operation is synchronous,
given that the I/O model on NT allows any call to be implemented
asynchronously. I’ve seen cases where APPLICATIONS have failed because they
request asynchronous I/O and (being the accomodating file systems types that
we are) we actually GIVE it to them - and they then “fall over” and fail to
handle it properly (ERR_IO_PENDING in a Win32 application on a file opened
for overlapped I/O.)
Ah, but for a driver to assume that its completion routine will be called at
PASSIVE_LEVEL is a bug. Indeed, I seem to recall that this is one of the
scenarios that the driver verifier’s I/O stress test will check (albeit at
some very high testing level.) It does this by calling all completion
routines at DISPATCH_LEVEL. I would suggest that this works in sfilter
because it is compatible with existing implementations, not because it
implies any inherent rule of the implementation.
In our filters, we routinely check for DISPATCH_LEVEL completion and, if we
receive same, we post the operation to a worker thread so that we can finish
the I/O in a safe thread context.
I hope this helps.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Robert McCrea [mailto:xxxxx@THE1VISION.com]
Sent: Tuesday, June 27, 2000 3:28 PM
To: File Systems Developers
Subject: [ntfsd] RE: problems with filter and IoRaiseHardError
Thanks Tony 
It turns out we have been making the assumption that mounts were synchronous
(is this a bad assumption??) If we change the mount code to an asynchronous
method the mount completes properly. The DFS gets the pending returned and
just decides to cancel the mount request and everything processes normally.
However, if the mount is asynchronous this will cause other problems in our
code… Unless, a mount completion is always called at passive level. The
sfilter example in the new IFS kit seems to imply that it is always called
at passive level because both IoAttachDeviceToDeviceStack and IoDeleteDevice
are called. Can anyone help out??
Thanks!!
Rob McCrea
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Monday, June 19, 2000 6:05 PM
To: File Systems Developers
Subject: [ntfsd] RE: problems with filter and IoRaiseHardError
The problem is that there is an APC that is not being delivered. Are you
calling at APC_LEVEL perchance? Using fast mutexes?
At any rate, look at the APC queue of the hung thread. I bet you find the
I/O completion APC sitting there waiting to run - it sets the event.
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@THE1VISION.com [mailto:xxxxx@THE1VISION.com]
Sent: Monday, June 19, 2000 3:37 PM
To: File Systems Developers
Subject: [ntfsd] problems with filter and IoRaiseHardError
We have a filter which is working under all platforms except for Win2000
server. In server when the DFS tries to issue a read on the floppy drive
(which is empty) we get stuck in a KeWaitForSingleObject. We get stuck
because our completion routine never gets called. I have traced this down
to the floppy driver and it returns a STATUS_NO_MEDIA_IN_DEVICE (which
seems to make sense) fastfat then does a IoRaiseHardError and returns
STATUS_PENDING. Then all is lost, the thread is stuck. When we are not
installed everything seems to work fine. Anybody have any ideas?
Thanks!!
Rob McCrea
1Vision Software Inc.
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You are currently subscribed to ntfsd as: xxxxx@THE1VISION.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)