RE: preventing recursive loop in create dispatch hand-----ler

Marc,

The point is that the original IRP_MJ_CREATE could be blocked while a
DIFFERENT thread accesses the (same) file. That doesn’t violate any rules
and is an implementation that I’ve seen numerous times.

Of course, it is possible to process an IRP_MJ_CREATE in arbitrary thread
context, but it isn’t common, and it can be complex (and FSD dependent) to
get it right. But the problems typically involve security context
(credentials) and not memory (since everything has been captured when the
IRP was constructed.) So this wasn’t the case that concerned me very much.

As anyone who has attended the PlugFests at Microsoft can attest,
filter-to-filter interactions are a serious problem. IRP_MJ_CREATE handling
has been a source of a fair number of those problems.

Regards,

Tony

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

-----Original Message-----
From: Marc Sherman [mailto:xxxxx@bionetrix.com]
Sent: Wednesday, July 12, 2000 2:52 PM
To: File Systems Developers
Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand ler

Tony,

I thought fsd entry points must be called in the context of the requesting
thread. This implies that fs filters should not cause any change in thread
context. In this case, it should be the same thread that originally called
ZWCreateFile.

Marc

> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com mailto:xxxxx]
> Sent: Wednesday, July 12, 2000 2:36 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: preventing recursive loop in create
> dispatch hand ler
>
>
> Marc,
>
> The general problem with such approaches is that they “work”
> until you begin
> to deal with interactions involving other filter drivers,
> when any change in
> thread context will cause you to deadlock (because the mutex is not
> available, the second thread blocks. The first thread waits
> for the second
> thread to finish.) This is a problem that can occur when
> someone else’s
> filter is using handles (and thus switches to a known thread
> context) or
> uses captive threads (in a user service, or even system threads.)
>
> Regards,
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com http: < http://www.osr.com
http: >
>
>
> -----Original Message-----
> From: Marc Sherman [mailto:xxxxx@bionetrix.com
mailto:xxxxx]
> Sent: Wednesday, July 12, 2000 2:32 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: preventing recursive loop in create
> dispatch hand ler
>
>
> Before calling ZWCreateFile, aquire a mutex, then check to
> see if you’ve
> aquired it recursively (mutex.Header.SignalState < 0). If
> this is true, your
> hadling the irp that resulted from your ZWCreateFile. Release
> the mutex and
> return. Remember to release your mutex after your ZWClose as
> well. This
> works for one of our filters.
>
> good luck,
> Marc
>
> -----Original Message-----
> From: Smith, Joel [mailto:xxxxx@ntpsoftware.com
mailto:xxxxx]
> Sent: Wednesday, July 12, 2000 2:21 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: preventing recursive loop in create
> dispatch hand ler
>
>
>
> Thanks,
> In my case, though, I need to open the file before
> the file system
> because it is important that I know the file’s size (if the
> file exists),
> and, of course, a create might change the file’s size (overwrite,
> superceded, etc). I suppose I could backup to the parent
> directory and do a
> directory query for the file in question to determine its
> size. Then again,
> I wonder if FsRtlGetFileSize is smart enough to work with a
> FILE_OBJECT that
> has not been opened yet? Anyway, I’d still be interested in
> answers to my
> original question because just recognizing a recursive open
> may be simpler
> than solving the problem another way (like I mention above).
>
> Thanks,
> Joel
>
> -----Original Message-----
> From: Pavel Hrdina [mailto:xxxxx@sodatsw.cz mailto:xxxxx
> < mailto:xxxxx@sodatsw.cz mailto:xxxxx >]
> Sent: Wednesday, July 12, 2000 2:09 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: preventing recursive loop in create
> dispatch handler
>
>
> The best solution is to let the FSD to process the desired open first
> and then you can read from the file. You do not need to close
> it because
> you’re using the same file object as the successful requestor
> of this create
>
> request.
>
> Paul
>
> > -----Pùvodní zpráva-----
> > Od: Smith, Joel [SMTP:xxxxx@ntpsoftware.com]
> > Odesláno: 12. èervence 2000 20:00
> > Komu: File Systems Developers
> > Pøedmìt: [ntfsd] preventing recursive loop in create
> dispatch handler
>
> >
> > Hello,
> > I know this has been asked before, and I apologize
> for asking
> > again, but…
> > Can anyone suggest a good way to prevent a
> recursive loop when
> > opening the destination file for a create in the create
> dispatch routine.
> >
> > for example:
> >
> > CreateDisptachHandler(device, irp)
> > {
> > -ZwCreateFile(target of create) - this will cause a
> > recursive loop, obviously
> >
> > -read some settings from file if it exists
> >
> > -ZwClose(target of create)
> > }
> >
> > I believe there is a ‘well known’ solution to this
> problem, but I
> > don’t know it.
> >
> > Thanks,
> > Joel
> >
>
> —
> You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@bionetrix.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></http:></mailto:xxxxx></http:>