RE: preventing recursive loop in create dispatch hand-ler

>>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
(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
it thinks is the bottom of the driver stack. They are some catches with
approach though. (ex: closehandle() is dangerous in this case, for example
you may re-enter the top of the stack because the iomanager will still use
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 ?


> -----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
>You are currently subscribed to ntfsd as:
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)