>>From my understanding of your idea you solve the recursion detection
problem not
the deadlock problem induced by reentering the stack ?
I didn’t think that I have a deadlock problem. We all may have the stack
overflow problem that Scott mentioned but this is a different problem.
>
In my implementation the shadow device is not attach to any other filter
device
(it is almost a perfect duplicate of the original device object) It use a
private interface in the driver with the original DO and talk directly to
what
it thinks is the bottom of the driver stack. They are some catches with
this
approach though. (ex: closehandle() is dangerous in this case, for example
as
you may re-enter the top of the stack because the iomanager will still use
the
original vpb to find the top of the stack, if I recall).
Now it sounds to me that your ‘shadow device’ is different from my
understanding of Tony’s idea. I think that with Tony’s implementation, you
have a ‘shadow device’ for each device that represents a volume. The special
ZwCreateFile() issued by the dispatch routine, will be issued using the
devicename of the shadow device. Why do you need private interfaces ?
Sara
> -----Original Message-----
> From: Tony Mason
>> To: File Systems Developers
>> Date: Thursday, July 13, 2000 8:04 AM
>> Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand
ler
>>
>>
>
>…
>
>>
>
>Jerome.
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@veritas.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>