If you want the default behavior to be taken, you *MUST* return
STATUS_INVALID_DEVICE_REQUEST from your Acquire/ReleaseForModWrite
handlers.
While FsRtlAcquireFileForModWriteEx will take the default behavior for
any non-success status other than STATUS_CANT_WAIT,
FsRtlReleaseFileForModWrite will take the default behavior *only* if you
return STATUS_INVALID_DEVICE_REQUEST. This inconsistency will be fixed
in the next service pack for each of Windows 2000 (SP5), Windows XP
(SP2) and Windows Server 2003 (SP1), but to make sure this bug doesn’t
affect your file system on any OS version, return
STATUS_INVALID_DEVICE_REQUEST in all cases when you want the default
lock processing.
Also, this *can* affect filter drivers as well, particularly if your
filter driver registers Fast IO handlers for these routines.
Historically, filters have been bypassed for these Fast IO operations
(which is why we introduced the FsFilter callbacks in Windows XP and
later), but if your filter works in DFS environments and attaches to a
redirector which could handle IO for the DFS, all IOs (including these
Fast IO acquire/release calls) redirected by DFS to the appropriate
redirector *will* start at the top of the redirector stack. Therefore,
on the Acquire/ReleaseForModWrite Fast IO calls, it will call the filter
drivers which have these Fast IO handlers registered.
If your filter is based off of the Sfilter sample in the NT 4.0 IFS Kit,
the sample code there was WRONG. It returns STATUS_NOT_IMPLEMENTED if
the next device in the stack did not register the appropriate Fast IO
handler. It should have returned STATUS_INVALID_DEVICE_REQUEST here
instead and this was fixed in all later versions of the IFS Kit samples
(both Sfilter and FileSpy).
Thanks,
Molly Brown
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nick Ryan
Sent: Thursday, December 04, 2003 12:36 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: Return values from AcquireForModWrite handler
A cursory examination of the disassembly of
FsRtlAcquireFileForModWriteEx indicates that the system treats all
non-zero return values from the FSD dispatch entry point identically
except for STATUS_CANT_WAIT.
David Markun wrote:
Hello All,
I heard here (11 August 2003) about something that seems it might be
useful to me. I have not seen this documented anywhere else,and would
like to hear any confirmation of this (ideally, by pointing to some
doc or code).
goto_vipul wrote on 11 August 2003 here:
>I understand that returning any status other than SUCCESS or CANT_WAIT
>will result in the default behavior (Main/PagingIo resource dependent
>on FCB->Flags)
My situation is that I am adding an
AcquireForModWrite/ReleaseForModWrite
to a filesystem (modeled on FastFat) which previously did not have
these routines and therefore depended on default behavior regarding
resource acquisition (as FastFat does). I am adding these routines
strictly for the purpose of refusing the Acquire if it arises during a
transient inconvenient condition that does not have anything to do
with acquiring the Main or PagingIo resources.
I would like to get default behavior in most cases. It looks like the
filespy.c filter returns STATUS_INVALID_DEVICE_REQUEST when it is
above an FS that does not specify an AcquireForModWrite entry point.
Therefore, it looks like I can probably get default handling if I
return STATUS_INVALID_DEVICE_REQUEST.
Anybody want to confirm or deny this?
Best regards,
David
–
Nick Ryan (MVP for DDK)
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