Tony,
I also cannot understand the problem that you see with Marc’s solution.
Marc’s solution is equivalent to a simpler and nicer solution of using top
level IRPs (IoGetTopLevelIrp()/IoSetTopLevelIrp) which will detect recursion
within a thread. We assume that when CreateDisptachHandler() is invoked a
second time (on behalf of it’s own ZwCreateFile()), it will happen in the
same thread context as the first CreateDisptachHandler(). Isn’t this always
a true assumption ? We don’t worry about other threads accessing the same
file.
Sara
-----Original Message-----
From: Tony Mason
To: File Systems Developers
Date: Wednesday, July 12, 2000 12:04 PM
Subject: [ntfsd] 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’)
>>
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@veritas.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></http:></mailto:xxxxx></http:>