Minifilter cache

[OSR_Community_User]

I thought as much (I seem to recall a comment about how this is going to
play in Vista with its support for asynchronous create operations.)

Note, however, that just because one is called at PASSIVE_LEVEL and in
the correct context, there is still no guarantee the allocation will
work at that point - which still leaves the ugly recovery semantics (and
is why I originally allocated everything in dispatch and discarded it in
free if I did not need it.)

Failures like this only show up when testing with memory allocation
failure logic or when a real system is melting down - exactly the WRONG
time to be testing your error recovery logic for the first time.

Regards,

Tony

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

[OSR_Community_User]

Creates are special. Because they are handled synchronously by both Io and
the file system (in current OS’s), there is no penalty attached to
synchronizing the completion back to the dispatch routine in a legacy filter
(like FltMgr). I presume that is how FltMgr guarantees PASSIVE_LEVEL for
post-create callbacks. Nevertheless, I think it is clearer, more correct,
and more likely to always work in the future if you return
FLT_PREOP_SYNCHRONIZE from the pre-create callback when you need a
PASSIVE_LEVEL post-create.

The CTX sample, when it encounters a failure in the post-create callback,
throws up it’s hands, says “oh, well”, and continues, ignoring the failure.
It is a sample. It is not robust. Tony’s method is much better for a
production filter.

• Dan.

----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 04, 2006 6:43 AM
Subject: RE: [ntfsd] Minifilter cache

I thought as much (I seem to recall a comment about how this is going to
play in Vista with its support for asynchronous create operations.)

Note, however, that just because one is called at PASSIVE_LEVEL and in
the correct context, there is still no guarantee the allocation will
work at that point - which still leaves the ugly recovery semantics (and
is why I originally allocated everything in dispatch and discarded it in
free if I did not need it.)

Failures like this only show up when testing with memory allocation
failure logic or when a real system is melting down - exactly the WRONG
time to be testing your error recovery logic for the first time.

Regards,

Tony

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

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

In my first post this morning, I was agreeing with Tony’s method, looked
dangerous to call fltallocate in post-create…

So if I got this straight, your saying post-creates will be called at
passive and the doc’s are misleading/wrong?

In the CTX example, you’re saying it will never invoke the callback at
Dispatch (Thus bugchecking after calling fltAllocateCon @ < APC)?

m

Dan Kyler wrote:

Creates are special. Because they are handled synchronously by both
Io and the file system (in current OS’s), there is no penalty attached
to synchronizing the completion back to the dispatch routine in a
legacy filter (like FltMgr). I presume that is how FltMgr guarantees
PASSIVE_LEVEL for post-create callbacks. Nevertheless, I think it is
clearer, more correct, and more likely to always work in the future if
you return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
need a PASSIVE_LEVEL post-create.

The CTX sample, when it encounters a failure in the post-create
callback, throws up it’s hands, says “oh, well”, and continues,
ignoring the failure. It is a sample. It is not robust. Tony’s
method is much better for a production filter.

• Dan.

----- Original Message ----- From: “Tony Mason”
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, May 04, 2006 6:43 AM
> Subject: RE: [ntfsd] Minifilter cache
>
>
> I thought as much (I seem to recall a comment about how this is going to
> play in Vista with its support for asynchronous create operations.)
>
> Note, however, that just because one is called at PASSIVE_LEVEL and in
> the correct context, there is still no guarantee the allocation will
> work at that point - which still leaves the ugly recovery semantics (and
> is why I originally allocated everything in dispatch and discarded it in
> free if I did not need it.)
>
> Failures like this only show up when testing with memory allocation
> failure logic or when a real system is melting down - exactly the WRONG
> time to be testing your error recovery logic for the first time.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

[Lyndon_J_Clarke-2]

No, you are confused, at the very least, and creates are handle special in
filter manager, that is clear, in the docs.

“MM” wrote in message news:xxxxx@ntfsd…
> No, “The Docs are Clear”; what is the difference is a post-create and a
> post-operation?:
>
> “A minifilter’s postoperation callback routine performs completion
> processing for one or more types of I/O operations.
>
> Postoperation callback routines are similar to the completion routines
> used by legacy file system filter drivers.
>
> Postoperation callback routines are called in an arbitrary thread context,
> at IRQL <= DISPATCH_LEVEL.
>
> Because this callback routine can be called at IRQL DISPATCH_LEVEL, it is
> subject to the following constraints:
>
> * It cannot safely call any kernel-mode routine that must run at a
> lower IRQL.”
>
>
>
>
>
>
> Lyndon J. Clarke wrote:
>
>>No. The docs are clear. "Post-create callback routines are called at IRQL
>>PASSIVE_LEVEL, in the context of the thread that originated the
>>IRP_MJ_CREATE operation. " This is distinct from completion of
>>IRP_MJ_CREATE in traditional (legacy) filter driver.
>>
>>“MM” wrote in message news:xxxxx@ntfsd…
>>
>>>Tony Mason wrote:
>>>
>>>
>>>>I always allocate the stream context in pre-create (so I can fail the
>>>>create operation in case of allocation failure) and then pass it to the
>>>>completion routine (that’s the general paradigm I use - allocate in
>>>>dispatch, use/free in completion.) Otherwise, in completion you get
>>>>stuck with complex failure handling (allocation fails, so you then get
>>>>into the “let’s cancel the open” error handling, etc.)
>>>>
>>>>
>>>I see in the doc’s FltAllocateContext must be running at IRQL <=
>>>APC_LEVEL,
>>>where Post-Create OP’s can be called at an IRQL <= Dispatch sometimes.
>>>Thus, it looks as if some of the samples
>>>in the wdk could result in an IRQL_NOT_LESS_OR_EQUAL bugcheck, maybe?
>>>
>>>Regarding IRQL’s: In the CTX mini filter example, post-create calls
>>>CtxFindOrCreateStreamContext
>>>which uses FltAllocateContext. When a a post-op callback is running at
>>>Dispatch and it calls a
>>>secondary function, does it’s IRQL remain where it’s at?
>>>
>>>Such a basic question, but I really don’t know - hanging my head in
>>>shame…
>>>
>>>m
>>>
>>>
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>

[Lyndon_J_Clarke-2]

Great advice!

“Tony Mason” wrote in message news:xxxxx@ntfsd…
I thought as much (I seem to recall a comment about how this is going to
play in Vista with its support for asynchronous create operations.)

Note, however, that just because one is called at PASSIVE_LEVEL and in
the correct context, there is still no guarantee the allocation will
work at that point - which still leaves the ugly recovery semantics (and
is why I originally allocated everything in dispatch and discarded it in
free if I did not need it.)

Failures like this only show up when testing with memory allocation
failure logic or when a real system is melting down - exactly the WRONG
time to be testing your error recovery logic for the first time.

Regards,

Tony

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

[OSR_Community_User]

> So if I got this straight, your saying post-creates will be called at

passive and the doc’s are misleading/wrong?

Yes to the first question, no to the second. As Lyndon pointed out, the
“Comments” section for PFLT_POST_OPERATION_CALLBACK (I’m looking at the 5308
WDK) first speaks of the general case (postop callbacks can be called at
dispatch), and then documents the exception (post create is always called at
passive). After the section you quoted, read on.

In the CTX example, you’re saying it will never invoke the callback at
Dispatch (Thus bugchecking after calling fltAllocateCon @ < APC)?
Correct. But as I said, I prefer to make it explicit by synchronizing.

• Dan.

----- Original Message -----
From: “MM”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 04, 2006 7:18 AM
Subject: Re: [ntfsd] Minifilter cache

> In my first post this morning, I was agreeing with Tony’s method, looked
> dangerous to call fltallocate in post-create…
>
> So if I got this straight, your saying post-creates will be called at
> passive and the doc’s are misleading/wrong?
>
> In the CTX example, you’re saying it will never invoke the callback at
> Dispatch (Thus bugchecking after calling fltAllocateCon @ < APC)?
>
> m
>
> Dan Kyler wrote:
>
>> Creates are special. Because they are handled synchronously by both Io
>> and the file system (in current OS’s), there is no penalty attached to
>> synchronizing the completion back to the dispatch routine in a legacy
>> filter (like FltMgr). I presume that is how FltMgr guarantees
>> PASSIVE_LEVEL for post-create callbacks. Nevertheless, I think it is
>> clearer, more correct, and more likely to always work in the future if
>> you return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
>> need a PASSIVE_LEVEL post-create.
>>
>> The CTX sample, when it encounters a failure in the post-create callback,
>> throws up it’s hands, says “oh, well”, and continues, ignoring the
>> failure. It is a sample. It is not robust. Tony’s method is much better
>> for a production filter.
>>
>> - Dan.
>>
>> ----- Original Message ----- From: “Tony Mason”
>> To: “Windows File Systems Devs Interest List”
>> Sent: Thursday, May 04, 2006 6:43 AM
>> Subject: RE: [ntfsd] Minifilter cache
>>
>>
>> I thought as much (I seem to recall a comment about how this is going to
>> play in Vista with its support for asynchronous create operations.)
>>
>> Note, however, that just because one is called at PASSIVE_LEVEL and in
>> the correct context, there is still no guarantee the allocation will
>> work at that point - which still leaves the ugly recovery semantics (and
>> is why I originally allocated everything in dispatch and discarded it in
>> free if I did not need it.)
>>
>> Failures like this only show up when testing with memory allocation
>> failure logic or when a real system is melting down - exactly the WRONG
>> time to be testing your error recovery logic for the first time.
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
>> ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

" I have a more omplex context management model anyway because I keep them
on a list in
the instance, so that I can unload the mini-filter at any time (I just
walk the instance lists and tear everything down…)"

No neeed in this afaik filter manager will remvoe your contexts and call
your context cleanup routines during FltUnregisterFilter.

[Lyndon_J_Clarke-2]

Dan

Note the docs says “Minifilters should not return FLT_PREOP_SYNCHRONIZE for
create operations, because these operations are already synchronized by the
Filter Manager. If a minifilter has registered preoperation and
postoperation callback routines for IRP_MJ_CREATE operations, the
post-create callback is called at IRQL PASSIVE_LEVEL, in the same thread
context as the pre-create callback.”. I dont think this is good, I agree
code would be clearer if pre-create callback returns FLT_PREOP_SYNCHRONIZE,
I just say, this is what the docs says.

Cheers
Lyndon

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> Creates are special. Because they are handled synchronously by both Io
> and the file system (in current OS’s), there is no penalty attached to
> synchronizing the completion back to the dispatch routine in a legacy
> filter (like FltMgr). I presume that is how FltMgr guarantees
> PASSIVE_LEVEL for post-create callbacks. Nevertheless, I think it is
> clearer, more correct, and more likely to always work in the future if you
> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you need a
> PASSIVE_LEVEL post-create.
>
> The CTX sample, when it encounters a failure in the post-create callback,
> throws up it’s hands, says “oh, well”, and continues, ignoring the
> failure. It is a sample. It is not robust. Tony’s method is much better
> for a production filter.
>
> - Dan.
>
> ----- Original Message -----
> From: “Tony Mason”
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, May 04, 2006 6:43 AM
> Subject: RE: [ntfsd] Minifilter cache
>
>
> I thought as much (I seem to recall a comment about how this is going to
> play in Vista with its support for asynchronous create operations.)
>
> Note, however, that just because one is called at PASSIVE_LEVEL and in
> the correct context, there is still no guarantee the allocation will
> work at that point - which still leaves the ugly recovery semantics (and
> is why I originally allocated everything in dispatch and discarded it in
> free if I did not need it.)
>
> Failures like this only show up when testing with memory allocation
> failure logic or when a real system is melting down - exactly the WRONG
> time to be testing your error recovery logic for the first time.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

[OSR_Community_User]

Hi Lyndon,

Thanks for the pointer to that. I had never noticed that statement before.
I wonder how that’s going to play with Vista’s asynchronous creates?

I see that the following paragraph also says one should never synchronize
reads and writes. I have always treated this as I did with legacy filters,
which is to never synchronize ASYNCHRONOUS reads and writes.

• Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Thursday, May 04, 2006 7:46 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Minifilter cache

Dan

Note the docs says “Minifilters should not return FLT_PREOP_SYNCHRONIZE for
create operations, because these operations are already synchronized by the
Filter Manager. If a minifilter has registered preoperation and
postoperation callback routines for IRP_MJ_CREATE operations, the
post-create callback is called at IRQL PASSIVE_LEVEL, in the same thread
context as the pre-create callback.”. I dont think this is good, I agree
code would be clearer if pre-create callback returns FLT_PREOP_SYNCHRONIZE,
I just say, this is what the docs says.

Cheers
Lyndon

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> Creates are special. Because they are handled synchronously by both
> Io
> and the file system (in current OS’s), there is no penalty attached to
> synchronizing the completion back to the dispatch routine in a legacy
> filter (like FltMgr). I presume that is how FltMgr guarantees
> PASSIVE_LEVEL for post-create callbacks. Nevertheless, I think it is
> clearer, more correct, and more likely to always work in the future if you

> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you need a
> PASSIVE_LEVEL post-create.
>
> The CTX sample, when it encounters a failure in the post-create
> callback,
> throws up it’s hands, says “oh, well”, and continues, ignoring the
> failure. It is a sample. It is not robust. Tony’s method is much better
> for a production filter.
>
> - Dan.
>
> ----- Original Message -----
> From: “Tony Mason”
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, May 04, 2006 6:43 AM
> Subject: RE: [ntfsd] Minifilter cache
>
>
> I thought as much (I seem to recall a comment about how this is going
> to play in Vista with its support for asynchronous create operations.)
>
> Note, however, that just because one is called at PASSIVE_LEVEL and in
> the correct context, there is still no guarantee the allocation will
> work at that point - which still leaves the ugly recovery semantics
> (and is why I originally allocated everything in dispatch and
> discarded it in free if I did not need it.)
>
> Failures like this only show up when testing with memory allocation
> failure logic or when a real system is melting down - exactly the
> WRONG time to be testing your error recovery logic for the first time.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument: ‘’ To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

Lyndon J. Clarke wrote:

No, you are confused,

Apparently I was… What I read in the archives combined with what I
saw in the doc’s at glance seemed to match.
The two sources combined appeared to indicate that ALL post-ops could be
called at dispatch.

at the very least,

I deserve that slap…

and creates are handle special in
filter manager, that is clear, in the docs.

All I can do here is apologize for wasting peoples time - sorry. Like I
said, a lot of what I read online
sunk in, and as I was reading threw the wdk doc’s, I guess as soon as I
read what validated what I had read
previously - well, nothing got threw after that (think headed I guess,
or just dumb(I’ll go with that)).

Trying to become invisible now

m

“MM” wrote in message news:xxxxx@ntfsd…
>
>
>>No, “The Docs are Clear”; what is the difference is a post-create and a
>>post-operation?:
>>
>>“A minifilter’s postoperation callback routine performs completion
>>processing for one or more types of I/O operations.
>>
>>Postoperation callback routines are similar to the completion routines
>>used by legacy file system filter drivers.
>>
>>Postoperation callback routines are called in an arbitrary thread context,
>>at IRQL <= DISPATCH_LEVEL.
>>
>>Because this callback routine can be called at IRQL DISPATCH_LEVEL, it is
>>subject to the following constraints:
>>
>> * It cannot safely call any kernel-mode routine that must run at a
>> lower IRQL.”
>>
>>
>>
>>
>>
>>
>>Lyndon J. Clarke wrote:
>>
>>
>>
>>>No. The docs are clear. "Post-create callback routines are called at IRQL
>>>PASSIVE_LEVEL, in the context of the thread that originated the
>>>IRP_MJ_CREATE operation. " This is distinct from completion of
>>>IRP_MJ_CREATE in traditional (legacy) filter driver.
>>>
>>>“MM” wrote in message news:xxxxx@ntfsd…
>>>
>>>
>>>
>>>>Tony Mason wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I always allocate the stream context in pre-create (so I can fail the
>>>>>create operation in case of allocation failure) and then pass it to the
>>>>>completion routine (that’s the general paradigm I use - allocate in
>>>>>dispatch, use/free in completion.) Otherwise, in completion you get
>>>>>stuck with complex failure handling (allocation fails, so you then get
>>>>>into the “let’s cancel the open” error handling, etc.)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I see in the doc’s FltAllocateContext must be running at IRQL <=
>>>>APC_LEVEL,
>>>>where Post-Create OP’s can be called at an IRQL <= Dispatch sometimes.
>>>>Thus, it looks as if some of the samples
>>>>in the wdk could result in an IRQL_NOT_LESS_OR_EQUAL bugcheck, maybe?
>>>>
>>>>Regarding IRQL’s: In the CTX mini filter example, post-create calls
>>>>CtxFindOrCreateStreamContext
>>>>which uses FltAllocateContext. When a a post-op callback is running at
>>>>Dispatch and it calls a
>>>>secondary function, does it’s IRQL remain where it’s at?
>>>>
>>>>Such a basic question, but I really don’t know - hanging my head in
>>>>shame…
>>>>
>>>>m
>>>>
>>>>
>>>>
>>>>
>>>
>>>—
>>>Questions? First check the IFS FAQ at
>>>https://www.osronline.com/article.cfm?id=17
>>>
>>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>>
>
>
>
>—
>Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

[Lyndon_J_Clarke-2]

Dan

I had wondered if the question of filter manager pre- and post- create
callbacks and vista asynchronous creates has arisen at recent plugfest?

In fact the following paragraph you refer to does say “asynchronous read or
write operations” in both 3790.1830 and 5365

Cheers
Lyndon

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> Hi Lyndon,
>
> Thanks for the pointer to that. I had never noticed that statement
> before.
> I wonder how that’s going to play with Vista’s asynchronous creates?
>
> I see that the following paragraph also says one should never synchronize
> reads and writes. I have always treated this as I did with legacy
> filters,
> which is to never synchronize ASYNCHRONOUS reads and writes.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
> Sent: Thursday, May 04, 2006 7:46 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Minifilter cache
>
>
> Dan
>
> Note the docs says “Minifilters should not return FLT_PREOP_SYNCHRONIZE
> for
> create operations, because these operations are already synchronized by
> the
> Filter Manager. If a minifilter has registered preoperation and
> postoperation callback routines for IRP_MJ_CREATE operations, the
> post-create callback is called at IRQL PASSIVE_LEVEL, in the same thread
> context as the pre-create callback.”. I dont think this is good, I agree
> code would be clearer if pre-create callback returns
> FLT_PREOP_SYNCHRONIZE,
> I just say, this is what the docs says.
>
> Cheers
> Lyndon
>
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> Creates are special. Because they are handled synchronously by both
>> Io
>> and the file system (in current OS’s), there is no penalty attached to
>> synchronizing the completion back to the dispatch routine in a legacy
>> filter (like FltMgr). I presume that is how FltMgr guarantees
>> PASSIVE_LEVEL for post-create callbacks. Nevertheless, I think it is
>> clearer, more correct, and more likely to always work in the future if
>> you
>
>> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you need a
>> PASSIVE_LEVEL post-create.
>>
>> The CTX sample, when it encounters a failure in the post-create
>> callback,
>> throws up it’s hands, says “oh, well”, and continues, ignoring the
>> failure. It is a sample. It is not robust. Tony’s method is much better
>> for a production filter.
>>
>> - Dan.
>>
>> ----- Original Message -----
>> From: “Tony Mason”
>> To: “Windows File Systems Devs Interest List”
>> Sent: Thursday, May 04, 2006 6:43 AM
>> Subject: RE: [ntfsd] Minifilter cache
>>
>>
>> I thought as much (I seem to recall a comment about how this is going
>> to play in Vista with its support for asynchronous create operations.)
>>
>> Note, however, that just because one is called at PASSIVE_LEVEL and in
>> the correct context, there is still no guarantee the allocation will
>> work at that point - which still leaves the ugly recovery semantics
>> (and is why I originally allocated everything in dispatch and
>> discarded it in free if I did not need it.)
>>
>> Failures like this only show up when testing with memory allocation
>> failure logic or when a real system is melting down - exactly the
>> WRONG time to be testing your error recovery logic for the first time.
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag
>> argument: ‘’ To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

[OSR_Community_User]

Hi Lyndon,

I had wondered if the question of filter manager pre- and post- create
callbacks and vista asynchronous creates has arisen at recent plugfest?

While the issue of asynch creates did come up, I don’t recall any discussion
of it in this context–just that if your driver is holding a create, you
need to be prepared to receive a cancel on it.

In fact the following paragraph you refer to does say "asynchronous read or

write operations" in both 3790.1830 and 5365

The word “asynchronous” appears have been excluded from my copy of 3790.1830
and 5308. Are we looking at the same section? PFLT_PRE_OPERATION_CALLBACK,
Comments section, penultimate paragraph?

• Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Thursday, May 04, 2006 8:36 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Minifilter cache

Dan

I had wondered if the question of filter manager pre- and post- create
callbacks and vista asynchronous creates has arisen at recent plugfest?

In fact the following paragraph you refer to does say “asynchronous read or
write operations” in both 3790.1830 and 5365

Cheers
Lyndon

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> Hi Lyndon,
>
> Thanks for the pointer to that. I had never noticed that statement
> before.
> I wonder how that’s going to play with Vista’s asynchronous creates?
>
> I see that the following paragraph also says one should never
> synchronize reads and writes. I have always treated this as I did
> with legacy filters, which is to never synchronize ASYNCHRONOUS reads
> and writes.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
> Clarke
> Sent: Thursday, May 04, 2006 7:46 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Minifilter cache
>
>
> Dan
>
> Note the docs says “Minifilters should not return
> FLT_PREOP_SYNCHRONIZE
> for
> create operations, because these operations are already synchronized by
> the
> Filter Manager. If a minifilter has registered preoperation and
> postoperation callback routines for IRP_MJ_CREATE operations, the
> post-create callback is called at IRQL PASSIVE_LEVEL, in the same thread
> context as the pre-create callback.”. I dont think this is good, I agree
> code would be clearer if pre-create callback returns
> FLT_PREOP_SYNCHRONIZE,
> I just say, this is what the docs says.
>
> Cheers
> Lyndon
>
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> Creates are special. Because they are handled synchronously by both
>> Io and the file system (in current OS’s), there is no penalty
>> attached to synchronizing the completion back to the dispatch routine
>> in a legacy filter (like FltMgr). I presume that is how FltMgr
>> guarantees PASSIVE_LEVEL for post-create callbacks. Nevertheless, I
>> think it is clearer, more correct, and more likely to always work in
>> the future if you
>
>> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
>> need a PASSIVE_LEVEL post-create.
>>
>> The CTX sample, when it encounters a failure in the post-create
>> callback, throws up it’s hands, says “oh, well”, and continues,
>> ignoring the failure. It is a sample. It is not robust. Tony’s
>> method is much better for a production filter.
>>
>> - Dan.
>>
>> ----- Original Message -----
>> From: “Tony Mason”
>> To: “Windows File Systems Devs Interest List”
>> Sent: Thursday, May 04, 2006 6:43 AM
>> Subject: RE: [ntfsd] Minifilter cache
>>
>>
>> I thought as much (I seem to recall a comment about how this is going
>> to play in Vista with its support for asynchronous create
>> operations.)
>>
>> Note, however, that just because one is called at PASSIVE_LEVEL and
>> in the correct context, there is still no guarantee the allocation
>> will work at that point - which still leaves the ugly recovery
>> semantics (and is why I originally allocated everything in dispatch
>> and discarded it in free if I did not need it.)
>>
>> Failures like this only show up when testing with memory allocation
>> failure logic or when a real system is melting down - exactly the
>> WRONG time to be testing your error recovery logic for the first
>> time.
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag
>> argument: ‘’ To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

>All I can do here is apologize for wasting peoples time - sorry.

Even though you missed a section in the docs, you instigated discussion that
I am finding interesting, and may help others. No need to become
completely invisible.

• Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Thursday, May 04, 2006 8:33 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Minifilter cache

Lyndon J. Clarke wrote:

No, you are confused,

Apparently I was… What I read in the archives combined with what I
saw in the doc’s at glance seemed to match.
The two sources combined appeared to indicate that ALL post-ops could be
called at dispatch.

at the very least,

I deserve that slap…

and creates are handle special in
filter manager, that is clear, in the docs.

All I can do here is apologize for wasting peoples time - sorry. Like I
said, a lot of what I read online
sunk in, and as I was reading threw the wdk doc’s, I guess as soon as I
read what validated what I had read
previously - well, nothing got threw after that (think headed I guess,
or just dumb(I’ll go with that)).

Trying to become invisible now

m

“MM” wrote in message news:xxxxx@ntfsd…
>
>
>>No, “The Docs are Clear”; what is the difference is a post-create and
>>a
>>post-operation?:
>>
>>“A minifilter’s postoperation callback routine performs completion
>>processing for one or more types of I/O operations.
>>
>>Postoperation callback routines are similar to the completion routines
>>used by legacy file system filter drivers.
>>
>>Postoperation callback routines are called in an arbitrary thread
>>context,
>>at IRQL <= DISPATCH_LEVEL.
>>
>>Because this callback routine can be called at IRQL DISPATCH_LEVEL, it
>>is
>>subject to the following constraints:
>>
>> * It cannot safely call any kernel-mode routine that must run at a
>> lower IRQL.”
>>
>>
>>
>>
>>
>>
>>Lyndon J. Clarke wrote:
>>
>>
>>
>>>No. The docs are clear. "Post-create callback routines are called at
>>>IRQL
>>>PASSIVE_LEVEL, in the context of the thread that originated the
>>>IRP_MJ_CREATE operation. " This is distinct from completion of
>>>IRP_MJ_CREATE in traditional (legacy) filter driver.
>>>
>>>“MM” wrote in message news:xxxxx@ntfsd…
>>>
>>>
>>>
>>>>Tony Mason wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I always allocate the stream context in pre-create (so I can fail
>>>>>the create operation in case of allocation failure) and then pass
>>>>>it to the completion routine (that’s the general paradigm I use -
>>>>>allocate in dispatch, use/free in completion.) Otherwise, in
>>>>>completion you get stuck with complex failure handling (allocation
>>>>>fails, so you then get into the “let’s cancel the open” error
>>>>>handling, etc.)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I see in the doc’s FltAllocateContext must be running at IRQL <=
>>>>APC_LEVEL,
>>>>where Post-Create OP’s can be called at an IRQL <= Dispatch sometimes.
>>>>Thus, it looks as if some of the samples
>>>>in the wdk could result in an IRQL_NOT_LESS_OR_EQUAL bugcheck, maybe?
>>>>
>>>>Regarding IRQL’s: In the CTX mini filter example, post-create calls
>>>>CtxFindOrCreateStreamContext
>>>>which uses FltAllocateContext. When a a post-op callback is running at
>>>>Dispatch and it calls a
>>>>secondary function, does it’s IRQL remain where it’s at?
>>>>
>>>>Such a basic question, but I really don’t know - hanging my head in
>>>>shame…
>>>>
>>>>m
>>>>
>>>>
>>>>
>>>>
>>>
>>>—
>>>Questions? First check the IFS FAQ at
>>>https://www.osronline.com/article.cfm?id=17
>>>
>>>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>>>unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>>
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

I see it now…“Returning FLT_PREOP_SYNCHRONIZE” section.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, May 04, 2006 8:54 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Minifilter cache

Hi Lyndon,

I had wondered if the question of filter manager pre- and post- create
callbacks and vista asynchronous creates has arisen at recent plugfest?

While the issue of asynch creates did come up, I don’t recall any discussion
of it in this context–just that if your driver is holding a create, you
need to be prepared to receive a cancel on it.

In fact the following paragraph you refer to does say "asynchronous
read or

write operations" in both 3790.1830 and 5365

The word “asynchronous” appears have been excluded from my copy of 3790.1830
and 5308. Are we looking at the same section? PFLT_PRE_OPERATION_CALLBACK,
Comments section, penultimate paragraph?

• Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Thursday, May 04, 2006 8:36 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Minifilter cache

Dan

I had wondered if the question of filter manager pre- and post- create
callbacks and vista asynchronous creates has arisen at recent plugfest?

In fact the following paragraph you refer to does say “asynchronous read or
write operations” in both 3790.1830 and 5365

Cheers
Lyndon

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> Hi Lyndon,
>
> Thanks for the pointer to that. I had never noticed that statement
> before. I wonder how that’s going to play with Vista’s asynchronous
> creates?
>
> I see that the following paragraph also says one should never
> synchronize reads and writes. I have always treated this as I did
> with legacy filters, which is to never synchronize ASYNCHRONOUS reads
> and writes.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
> Clarke
> Sent: Thursday, May 04, 2006 7:46 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Minifilter cache
>
>
> Dan
>
> Note the docs says “Minifilters should not return
> FLT_PREOP_SYNCHRONIZE
> for
> create operations, because these operations are already synchronized by
> the
> Filter Manager. If a minifilter has registered preoperation and
> postoperation callback routines for IRP_MJ_CREATE operations, the
> post-create callback is called at IRQL PASSIVE_LEVEL, in the same thread
> context as the pre-create callback.”. I dont think this is good, I agree
> code would be clearer if pre-create callback returns
> FLT_PREOP_SYNCHRONIZE,
> I just say, this is what the docs says.
>
> Cheers
> Lyndon
>
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> Creates are special. Because they are handled synchronously by both
>> Io and the file system (in current OS’s), there is no penalty
>> attached to synchronizing the completion back to the dispatch routine
>> in a legacy filter (like FltMgr). I presume that is how FltMgr
>> guarantees PASSIVE_LEVEL for post-create callbacks. Nevertheless, I
>> think it is clearer, more correct, and more likely to always work in
>> the future if you
>
>> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
>> need a PASSIVE_LEVEL post-create.
>>
>> The CTX sample, when it encounters a failure in the post-create
>> callback, throws up it’s hands, says “oh, well”, and continues,
>> ignoring the failure. It is a sample. It is not robust. Tony’s
>> method is much better for a production filter.
>>
>> - Dan.
>>
>> ----- Original Message -----
>> From: “Tony Mason”
>> To: “Windows File Systems Devs Interest List”
>> Sent: Thursday, May 04, 2006 6:43 AM
>> Subject: RE: [ntfsd] Minifilter cache
>>
>>
>> I thought as much (I seem to recall a comment about how this is going
>> to play in Vista with its support for asynchronous create
>> operations.)
>>
>> Note, however, that just because one is called at PASSIVE_LEVEL and
>> in the correct context, there is still no guarantee the allocation
>> will work at that point - which still leaves the ugly recovery
>> semantics (and is why I originally allocated everything in dispatch
>> and discarded it in free if I did not need it.)
>>
>> Failures like this only show up when testing with memory allocation
>> failure logic or when a real system is melting down - exactly the
>> WRONG time to be testing your error recovery logic for the first
>> time.
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag
>> argument: ‘’ To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Hey Matt

No need to apologize to me; I know I have been in the same situation as you
and had the benefit of the patience and kindness of contributors on these
lits. The reading of document can be a bit of an art form

Good luck
Lyndon

“MM” wrote in message news:xxxxx@ntfsd…
> Lyndon J. Clarke wrote:
>
>>No, you are confused,
>>
> Apparently I was… What I read in the archives combined with what I saw
> in the doc’s at glance seemed to match.
> The two sources combined appeared to indicate that ALL post-ops could be
> called at dispatch.
>
>> at the very least,
>>
> I deserve that slap…
>
>> and creates are handle special in filter manager, that is clear, in the
>> docs.
>>
> All I can do here is apologize for wasting peoples time - sorry. Like I
> said, a lot of what I read online
> sunk in, and as I was reading threw the wdk doc’s, I guess as soon as I
> read what validated what I had read
> previously - well, nothing got threw after that (think headed I guess, or
> just dumb(I’ll go with that)).
>
> Trying to become invisible now
>
> m
>
>
>>“MM” wrote in message news:xxxxx@ntfsd…
>>
>>>No, “The Docs are Clear”; what is the difference is a post-create and a
>>>post-operation?:
>>>
>>>“A minifilter’s postoperation callback routine performs completion
>>>processing for one or more types of I/O operations.
>>>
>>>Postoperation callback routines are similar to the completion routines
>>>used by legacy file system filter drivers.
>>>
>>>Postoperation callback routines are called in an arbitrary thread
>>>context, at IRQL <= DISPATCH_LEVEL.
>>>
>>>Because this callback routine can be called at IRQL DISPATCH_LEVEL, it is
>>>subject to the following constraints:
>>>
>>> * It cannot safely call any kernel-mode routine that must run at a
>>> lower IRQL.”
>>>
>>>
>>>
>>>
>>>
>>>
>>>Lyndon J. Clarke wrote:
>>>
>>>
>>>>No. The docs are clear. "Post-create callback routines are called at
>>>>IRQL PASSIVE_LEVEL, in the context of the thread that originated the
>>>>IRP_MJ_CREATE operation. " This is distinct from completion of
>>>>IRP_MJ_CREATE in traditional (legacy) filter driver.
>>>>
>>>>“MM” wrote in message news:xxxxx@ntfsd…
>>>>
>>>>
>>>>>Tony Mason wrote:
>>>>>
>>>>>
>>>>>
>>>>>>I always allocate the stream context in pre-create (so I can fail the
>>>>>>create operation in case of allocation failure) and then pass it to
>>>>>>the
>>>>>>completion routine (that’s the general paradigm I use - allocate in
>>>>>>dispatch, use/free in completion.) Otherwise, in completion you get
>>>>>>stuck with complex failure handling (allocation fails, so you then get
>>>>>>into the “let’s cancel the open” error handling, etc.)
>>>>>>
>>>>>>
>>>>>>
>>>>>I see in the doc’s FltAllocateContext must be running at IRQL <=
>>>>>APC_LEVEL,
>>>>>where Post-Create OP’s can be called at an IRQL <= Dispatch sometimes.
>>>>>Thus, it looks as if some of the samples
>>>>>in the wdk could result in an IRQL_NOT_LESS_OR_EQUAL bugcheck, maybe?
>>>>>
>>>>>Regarding IRQL’s: In the CTX mini filter example, post-create calls
>>>>>CtxFindOrCreateStreamContext
>>>>>which uses FltAllocateContext. When a a post-op callback is running at
>>>>>Dispatch and it calls a
>>>>>secondary function, does it’s IRQL remain where it’s at?
>>>>>
>>>>>Such a basic question, but I really don’t know - hanging my head in
>>>>>shame…
>>>>>
>>>>>m
>>>>>
>>>>>
>>>>>
>>>>
>>>>—
>>>>Questions? First check the IFS FAQ at
>>>>https://www.osronline.com/article.cfm?id=17
>>>>
>>>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>>
>>>>
>>>>
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>

[Lyndon_J_Clarke-2]

That is the page and on the page you mention I do nto have the word
“asynchronous” howwever that para seems to refer only to performance. I
guess you agree with the comment I said in a response to another poster in
the thread that reading the documentation can be an art form

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>I see it now…“Returning FLT_PREOP_SYNCHRONIZE” section.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Thursday, May 04, 2006 8:54 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] Minifilter cache
>
>
> Hi Lyndon,
>
>>I had wondered if the question of filter manager pre- and post- create
>>callbacks and vista asynchronous creates has arisen at recent plugfest?
>
> While the issue of asynch creates did come up, I don’t recall any
> discussion
> of it in this context–just that if your driver is holding a create, you
> need to be prepared to receive a cancel on it.
>
>>In fact the following paragraph you refer to does say “asynchronous
>>read or
>
>>write operations” in both 3790.1830 and 5365
>
> The word “asynchronous” appears have been excluded from my copy of
> 3790.1830
> and 5308. Are we looking at the same section?
> PFLT_PRE_OPERATION_CALLBACK,
> Comments section, penultimate paragraph?
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
> Sent: Thursday, May 04, 2006 8:36 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Minifilter cache
>
>
> Dan
>
> I had wondered if the question of filter manager pre- and post- create
> callbacks and vista asynchronous creates has arisen at recent plugfest?
>
> In fact the following paragraph you refer to does say “asynchronous read
> or
> write operations” in both 3790.1830 and 5365
>
> Cheers
> Lyndon
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> Hi Lyndon,
>>
>> Thanks for the pointer to that. I had never noticed that statement
>> before. I wonder how that’s going to play with Vista’s asynchronous
>> creates?
>>
>> I see that the following paragraph also says one should never
>> synchronize reads and writes. I have always treated this as I did
>> with legacy filters, which is to never synchronize ASYNCHRONOUS reads
>> and writes.
>>
>> - Dan.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
>> Clarke
>> Sent: Thursday, May 04, 2006 7:46 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] Minifilter cache
>>
>>
>> Dan
>>
>> Note the docs says “Minifilters should not return
>> FLT_PREOP_SYNCHRONIZE
>> for
>> create operations, because these operations are already synchronized by
>> the
>> Filter Manager. If a minifilter has registered preoperation and
>> postoperation callback routines for IRP_MJ_CREATE operations, the
>> post-create callback is called at IRQL PASSIVE_LEVEL, in the same thread
>> context as the pre-create callback.”. I dont think this is good, I agree
>> code would be clearer if pre-create callback returns
>> FLT_PREOP_SYNCHRONIZE,
>> I just say, this is what the docs says.
>>
>> Cheers
>> Lyndon
>>
>>
>> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>>> Creates are special. Because they are handled synchronously by both
>>> Io and the file system (in current OS’s), there is no penalty
>>> attached to synchronizing the completion back to the dispatch routine
>>> in a legacy filter (like FltMgr). I presume that is how FltMgr
>>> guarantees PASSIVE_LEVEL for post-create callbacks. Nevertheless, I
>>> think it is clearer, more correct, and more likely to always work in
>>> the future if you
>>
>>> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
>>> need a PASSIVE_LEVEL post-create.
>>>
>>> The CTX sample, when it encounters a failure in the post-create
>>> callback, throws up it’s hands, says “oh, well”, and continues,
>>> ignoring the failure. It is a sample. It is not robust. Tony’s
>>> method is much better for a production filter.
>>>
>>> - Dan.
>>>
>>> ----- Original Message -----
>>> From: “Tony Mason”
>>> To: “Windows File Systems Devs Interest List”
>>> Sent: Thursday, May 04, 2006 6:43 AM
>>> Subject: RE: [ntfsd] Minifilter cache
>>>
>>>
>>> I thought as much (I seem to recall a comment about how this is going
>>> to play in Vista with its support for asynchronous create
>>> operations.)
>>>
>>> Note, however, that just because one is called at PASSIVE_LEVEL and
>>> in the correct context, there is still no guarantee the allocation
>>> will work at that point - which still leaves the ugly recovery
>>> semantics (and is why I originally allocated everything in dispatch
>>> and discarded it in free if I did not need it.)
>>>
>>> Failures like this only show up when testing with memory allocation
>>> failure logic or when a real system is melting down - exactly the
>>> WRONG time to be testing your error recovery logic for the first
>>> time.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> Tony Mason
>>> Consulting Partner
>>> OSR Open Systems Resources, Inc.
>>> http://www.osr.com
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: unknown lmsubst tag
>>> argument: ‘’ To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

[OSR_Community_User]

FYI, I have filed a beta bug against the WDK docs for the inconsistent
wording between the different sections.

• Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Thursday, May 04, 2006 9:28 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Minifilter cache

That is the page and on the page you mention I do nto have the word
“asynchronous” howwever that para seems to refer only to performance. I
guess you agree with the comment I said in a response to another poster in
the thread that reading the documentation can be an art form

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>I see it now…“Returning FLT_PREOP_SYNCHRONIZE” section.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Thursday, May 04, 2006 8:54 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] Minifilter cache
>
>
> Hi Lyndon,
>
>>I had wondered if the question of filter manager pre- and post- create
>>callbacks and vista asynchronous creates has arisen at recent
>>plugfest?
>
> While the issue of asynch creates did come up, I don’t recall any
> discussion
> of it in this context–just that if your driver is holding a create, you
> need to be prepared to receive a cancel on it.
>
>>In fact the following paragraph you refer to does say “asynchronous
>>read or
>
>>write operations” in both 3790.1830 and 5365
>
> The word “asynchronous” appears have been excluded from my copy of
> 3790.1830
> and 5308. Are we looking at the same section?
> PFLT_PRE_OPERATION_CALLBACK,
> Comments section, penultimate paragraph?
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
> Clarke
> Sent: Thursday, May 04, 2006 8:36 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Minifilter cache
>
>
> Dan
>
> I had wondered if the question of filter manager pre- and post- create
> callbacks and vista asynchronous creates has arisen at recent
> plugfest?
>
> In fact the following paragraph you refer to does say “asynchronous
> read
> or
> write operations” in both 3790.1830 and 5365
>
> Cheers
> Lyndon
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> Hi Lyndon,
>>
>> Thanks for the pointer to that. I had never noticed that statement
>> before. I wonder how that’s going to play with Vista’s asynchronous
>> creates?
>>
>> I see that the following paragraph also says one should never
>> synchronize reads and writes. I have always treated this as I did
>> with legacy filters, which is to never synchronize ASYNCHRONOUS reads
>> and writes.
>>
>> - Dan.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
>> Clarke
>> Sent: Thursday, May 04, 2006 7:46 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] Minifilter cache
>>
>>
>> Dan
>>
>> Note the docs says “Minifilters should not return
>> FLT_PREOP_SYNCHRONIZE for
>> create operations, because these operations are already synchronized by
>> the
>> Filter Manager. If a minifilter has registered preoperation and
>> postoperation callback routines for IRP_MJ_CREATE operations, the
>> post-create callback is called at IRQL PASSIVE_LEVEL, in the same thread
>> context as the pre-create callback.”. I dont think this is good, I agree
>> code would be clearer if pre-create callback returns
>> FLT_PREOP_SYNCHRONIZE,
>> I just say, this is what the docs says.
>>
>> Cheers
>> Lyndon
>>
>>
>> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>>> Creates are special. Because they are handled synchronously by both
>>> Io and the file system (in current OS’s), there is no penalty
>>> attached to synchronizing the completion back to the dispatch
>>> routine in a legacy filter (like FltMgr). I presume that is how
>>> FltMgr guarantees PASSIVE_LEVEL for post-create callbacks.
>>> Nevertheless, I think it is clearer, more correct, and more likely
>>> to always work in the future if you
>>
>>> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
>>> need a PASSIVE_LEVEL post-create.
>>>
>>> The CTX sample, when it encounters a failure in the post-create
>>> callback, throws up it’s hands, says “oh, well”, and continues,
>>> ignoring the failure. It is a sample. It is not robust. Tony’s
>>> method is much better for a production filter.
>>>
>>> - Dan.
>>>
>>> ----- Original Message -----
>>> From: “Tony Mason”
>>> To: “Windows File Systems Devs Interest List”
>>> Sent: Thursday, May 04, 2006 6:43 AM
>>> Subject: RE: [ntfsd] Minifilter cache
>>>
>>>
>>> I thought as much (I seem to recall a comment about how this is
>>> going to play in Vista with its support for asynchronous create
>>> operations.)
>>>
>>> Note, however, that just because one is called at PASSIVE_LEVEL and
>>> in the correct context, there is still no guarantee the allocation
>>> will work at that point - which still leaves the ugly recovery
>>> semantics (and is why I originally allocated everything in dispatch
>>> and discarded it in free if I did not need it.)
>>>
>>> Failures like this only show up when testing with memory allocation
>>> failure logic or when a real system is melting down - exactly the
>>> WRONG time to be testing your error recovery logic for the first
>>> time.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> Tony Mason
>>> Consulting Partner
>>> OSR Open Systems Resources, Inc.
>>> http://www.osr.com
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: unknown lmsubst tag
>>> argument: ‘’ To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

Vista does not have asynchronous creates. Creates are still synchronous
and i/o manager waits for them to complete. In case of mini-filters,
filter manager waits for them to complete. You could return status
pending for creates before vista, and you can in vista as well.

The only difference is that in Vista, if you set a cancel routine and
return pending, it will be invoked. Prior to Vista, cancel routines for
creates were never invoked, so creates were un-cancellable.

SO FLT_PREOP_SYNCHRONIZE has fundamentally not changed, and the same
recommendations apply: but in addition filter manager will ensure that
that operation for which FLT_PREOP_SYNCHRONIZE was returned (and for
creates implicitly), it will wait for the i/o to complete in a
cancellable way and cancel the i/o (and the create). This is something
that filter manager will do Vista release.
Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, May 04, 2006 9:00 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Minifilter cache

FYI, I have filed a beta bug against the WDK docs for the inconsistent
wording between the different sections.

• Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Thursday, May 04, 2006 9:28 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Minifilter cache

That is the page and on the page you mention I do nto have the word
“asynchronous” howwever that para seems to refer only to performance. I
guess you agree with the comment I said in a response to another poster
in
the thread that reading the documentation can be an art form

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>I see it now…“Returning FLT_PREOP_SYNCHRONIZE” section.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Thursday, May 04, 2006 8:54 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] Minifilter cache
>
>
> Hi Lyndon,
>
>>I had wondered if the question of filter manager pre- and post- create

>>callbacks and vista asynchronous creates has arisen at recent
>>plugfest?
>
> While the issue of asynch creates did come up, I don’t recall any
> discussion
> of it in this context–just that if your driver is holding a create,
you
> need to be prepared to receive a cancel on it.
>
>>In fact the following paragraph you refer to does say “asynchronous
>>read or
>
>>write operations” in both 3790.1830 and 5365
>
> The word “asynchronous” appears have been excluded from my copy of
> 3790.1830
> and 5308. Are we looking at the same section?
> PFLT_PRE_OPERATION_CALLBACK,
> Comments section, penultimate paragraph?
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
> Clarke
> Sent: Thursday, May 04, 2006 8:36 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Minifilter cache
>
>
> Dan
>
> I had wondered if the question of filter manager pre- and post- create

> callbacks and vista asynchronous creates has arisen at recent
> plugfest?
>
> In fact the following paragraph you refer to does say “asynchronous
> read
> or
> write operations” in both 3790.1830 and 5365
>
> Cheers
> Lyndon
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> Hi Lyndon,
>>
>> Thanks for the pointer to that. I had never noticed that statement
>> before. I wonder how that’s going to play with Vista’s asynchronous
>> creates?
>>
>> I see that the following paragraph also says one should never
>> synchronize reads and writes. I have always treated this as I did
>> with legacy filters, which is to never synchronize ASYNCHRONOUS reads

>> and writes.
>>
>> - Dan.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
>> Clarke
>> Sent: Thursday, May 04, 2006 7:46 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] Minifilter cache
>>
>>
>> Dan
>>
>> Note the docs says “Minifilters should not return
>> FLT_PREOP_SYNCHRONIZE for
>> create operations, because these operations are already synchronized
by
>> the
>> Filter Manager. If a minifilter has registered preoperation and
>> postoperation callback routines for IRP_MJ_CREATE operations, the
>> post-create callback is called at IRQL PASSIVE_LEVEL, in the same
thread
>> context as the pre-create callback.”. I dont think this is good, I
agree
>> code would be clearer if pre-create callback returns
>> FLT_PREOP_SYNCHRONIZE,
>> I just say, this is what the docs says.
>>
>> Cheers
>> Lyndon
>>
>>
>> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>>> Creates are special. Because they are handled synchronously by both

>>> Io and the file system (in current OS’s), there is no penalty
>>> attached to synchronizing the completion back to the dispatch
>>> routine in a legacy filter (like FltMgr). I presume that is how
>>> FltMgr guarantees PASSIVE_LEVEL for post-create callbacks.
>>> Nevertheless, I think it is clearer, more correct, and more likely
>>> to always work in the future if you
>>
>>> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
>>> need a PASSIVE_LEVEL post-create.
>>>
>>> The CTX sample, when it encounters a failure in the post-create
>>> callback, throws up it’s hands, says “oh, well”, and continues,
>>> ignoring the failure. It is a sample. It is not robust. Tony’s
>>> method is much better for a production filter.
>>>
>>> - Dan.
>>>
>>> ----- Original Message -----
>>> From: “Tony Mason”
>>> To: “Windows File Systems Devs Interest List”
>>> Sent: Thursday, May 04, 2006 6:43 AM
>>> Subject: RE: [ntfsd] Minifilter cache
>>>
>>>
>>> I thought as much (I seem to recall a comment about how this is
>>> going to play in Vista with its support for asynchronous create
>>> operations.)
>>>
>>> Note, however, that just because one is called at PASSIVE_LEVEL and
>>> in the correct context, there is still no guarantee the allocation
>>> will work at that point - which still leaves the ugly recovery
>>> semantics (and is why I originally allocated everything in dispatch
>>> and discarded it in free if I did not need it.)
>>>
>>> Failures like this only show up when testing with memory allocation
>>> failure logic or when a real system is melting down - exactly the
>>> WRONG time to be testing your error recovery logic for the first
>>> time.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> Tony Mason
>>> Consulting Partner
>>> OSR Open Systems Resources, Inc.
>>> http://www.osr.com
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: unknown lmsubst tag
>>> argument: ‘’ To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

Thanks, Ravi. That clears things up.

• Dan.

----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 04, 2006 12:23 PM
Subject: RE: [ntfsd] Minifilter cache

Vista does not have asynchronous creates. Creates are still synchronous
and i/o manager waits for them to complete. In case of mini-filters,
filter manager waits for them to complete. You could return status
pending for creates before vista, and you can in vista as well.

The only difference is that in Vista, if you set a cancel routine and
return pending, it will be invoked. Prior to Vista, cancel routines for
creates were never invoked, so creates were un-cancellable.

SO FLT_PREOP_SYNCHRONIZE has fundamentally not changed, and the same
recommendations apply: but in addition filter manager will ensure that
that operation for which FLT_PREOP_SYNCHRONIZE was returned (and for
creates implicitly), it will wait for the i/o to complete in a
cancellable way and cancel the i/o (and the create). This is something
that filter manager will do Vista release.
Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, May 04, 2006 9:00 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Minifilter cache

FYI, I have filed a beta bug against the WDK docs for the inconsistent
wording between the different sections.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Thursday, May 04, 2006 9:28 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Minifilter cache

That is the page and on the page you mention I do nto have the word
“asynchronous” howwever that para seems to refer only to performance. I
guess you agree with the comment I said in a response to another poster
in
the thread that reading the documentation can be an art form

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>I see it now…“Returning FLT_PREOP_SYNCHRONIZE” section.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Thursday, May 04, 2006 8:54 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] Minifilter cache
>
>
> Hi Lyndon,
>
>>I had wondered if the question of filter manager pre- and post- create

>>callbacks and vista asynchronous creates has arisen at recent
>>plugfest?
>
> While the issue of asynch creates did come up, I don’t recall any
> discussion
> of it in this context–just that if your driver is holding a create,
you
> need to be prepared to receive a cancel on it.
>
>>In fact the following paragraph you refer to does say “asynchronous
>>read or
>
>>write operations” in both 3790.1830 and 5365
>
> The word “asynchronous” appears have been excluded from my copy of
> 3790.1830
> and 5308. Are we looking at the same section?
> PFLT_PRE_OPERATION_CALLBACK,
> Comments section, penultimate paragraph?
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
> Clarke
> Sent: Thursday, May 04, 2006 8:36 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Minifilter cache
>
>
> Dan
>
> I had wondered if the question of filter manager pre- and post- create

> callbacks and vista asynchronous creates has arisen at recent
> plugfest?
>
> In fact the following paragraph you refer to does say “asynchronous
> read
> or
> write operations” in both 3790.1830 and 5365
>
> Cheers
> Lyndon
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> Hi Lyndon,
>>
>> Thanks for the pointer to that. I had never noticed that statement
>> before. I wonder how that’s going to play with Vista’s asynchronous
>> creates?
>>
>> I see that the following paragraph also says one should never
>> synchronize reads and writes. I have always treated this as I did
>> with legacy filters, which is to never synchronize ASYNCHRONOUS reads

>> and writes.
>>
>> - Dan.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
>> Clarke
>> Sent: Thursday, May 04, 2006 7:46 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] Minifilter cache
>>
>>
>> Dan
>>
>> Note the docs says “Minifilters should not return
>> FLT_PREOP_SYNCHRONIZE for
>> create operations, because these operations are already synchronized
by
>> the
>> Filter Manager. If a minifilter has registered preoperation and
>> postoperation callback routines for IRP_MJ_CREATE operations, the
>> post-create callback is called at IRQL PASSIVE_LEVEL, in the same
thread
>> context as the pre-create callback.”. I dont think this is good, I
agree
>> code would be clearer if pre-create callback returns
>> FLT_PREOP_SYNCHRONIZE,
>> I just say, this is what the docs says.
>>
>> Cheers
>> Lyndon
>>
>>
>> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
>>> Creates are special. Because they are handled synchronously by both

>>> Io and the file system (in current OS’s), there is no penalty
>>> attached to synchronizing the completion back to the dispatch
>>> routine in a legacy filter (like FltMgr). I presume that is how
>>> FltMgr guarantees PASSIVE_LEVEL for post-create callbacks.
>>> Nevertheless, I think it is clearer, more correct, and more likely
>>> to always work in the future if you
>>
>>> return FLT_PREOP_SYNCHRONIZE from the pre-create callback when you
>>> need a PASSIVE_LEVEL post-create.
>>>
>>> The CTX sample, when it encounters a failure in the post-create
>>> callback, throws up it’s hands, says “oh, well”, and continues,
>>> ignoring the failure. It is a sample. It is not robust. Tony’s
>>> method is much better for a production filter.
>>>
>>> - Dan.
>>>
>>> ----- Original Message -----
>>> From: “Tony Mason”
>>> To: “Windows File Systems Devs Interest List”
>>> Sent: Thursday, May 04, 2006 6:43 AM
>>> Subject: RE: [ntfsd] Minifilter cache
>>>
>>>
>>> I thought as much (I seem to recall a comment about how this is
>>> going to play in Vista with its support for asynchronous create
>>> operations.)
>>>
>>> Note, however, that just because one is called at PASSIVE_LEVEL and
>>> in the correct context, there is still no guarantee the allocation
>>> will work at that point - which still leaves the ugly recovery
>>> semantics (and is why I originally allocated everything in dispatch
>>> and discarded it in free if I did not need it.)
>>>
>>> Failures like this only show up when testing with memory allocation
>>> failure logic or when a real system is melting down - exactly the
>>> WRONG time to be testing your error recovery logic for the first
>>> time.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> Tony Mason
>>> Consulting Partner
>>> OSR Open Systems Resources, Inc.
>>> http://www.osr.com
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: unknown lmsubst tag
>>> argument: ‘’ To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

In all fairness, we need to be VERY cautious here - stating that “Vista
does not have asynchronous creates” could be interpreted to mean “Vista
has changed the I/O Management model to disallow asynchronous creates”.
Note that *asynchronous* creates have always been allowed in the
previous model. This could mean three things:

(1) That a caller could request asynchrony for a create (keep in mind,
there are other sources of IRPs than the I/O Manager);
(2) A driver may return STATUS_PENDING to an IRP_MJ_CREATE (FAT and NTFS
both do this under certain circumstances.)
(3) The I/O Manager does not send asynchronous creates.

I think Ravi means (3) and not (1) or (2) because those would constitute
a major change in the I/O Manager interface that could lead to
compatibility problems. I want to be clear on what his statement means
because it is likely to be misinterpreted in the future (e.g. to argue
that a file system driver cannot return STATUS_PENDING for an
IRP_MJ_CREATE call.)

It is a pity that asynch create isn’t implemented in the I/O Manager
because it sure would be nice to be able to queue up a few hundred opens
to a network drive rather than being forced to create a few hundred
threads to simulate asynchronous open. But hey, creating hundreds of
threads is cheap compared to the complexity of asynchronous I/O, right?

Such is life.

Regards,

Tony

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