STATUS_SHARING_VIOLATION while filtering mrxsmb redirector?

NTFSD
1

Hi,
I was wondering if anyone has had a similar problem to this one and
if it was solvable… I am a filter filtering the mrxsmb redirector on XP
SP1 and using the stream file alternative to IoCancelFileOpen; that is, I
clone the fileobject and do the CREATE with the cloned object before sending
down the “real” CREATE. After creating my cloned FILE_OBJECT, I send down a
CLEANUP IRP on it to allow any sharing state to be released, and I hold on
to my FILE_OBJECT reference. Then I send down the real CREATE. This works
great on FAT and NTFS, but when filtering the redirector, I am having
problems with the real CREATE failing with STATUS_SHARING_VIOLATION,
apparently because I still have a reference to my clone file object.
Digging into some assembly, I found the error code to be returned by
SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like this:

ChildEBP RetAddr Args to Child
f71eae60 f81f7da4 820da468 00000000 820da468
mrxsmb!SmbPseContinueOrdinaryExchange+0x15
f71eae90 f81ef4e4 00000000 00000028 00000000
mrxsmb!SmbPseOrdinaryExchange+0x1b7
f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
mrxsmb!SmbPseExchangeStart_Create+0x328
f71eaee8 f81f6d47 820da468 00000005 e1289008
mrxsmb!SmbPseExchangeStart_default+0xe
f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
mrxsmb!SmbCeInitiateExchange+0x29d
f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
f71eafa0 f8230557 81eaa488 00000004 e10b2c18
rdbss!RxCollapseOrCreateSrvOpen+0xf4
f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48 rdbss!RxCreateFromNetRoot+0x2ba
f71eb064 f8225920 81eaa488 820ad888 f822e030 rdbss!RxCommonCreate+0x2e0
f71eb108 f822ec97 f822e030 827dcf00 827dcfb8 rdbss!RxFsdCommonDispatch+0x333
f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
f71eb150 80a20812 00000000 017dcf48 8204d9a8 mrxsmb!MRxSmbFsdDispatch+0x132
f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
f71eb510 80a20812 81f64540 827dcf48 81f64540 mydriver!MyDriverCreate+0xe0a
[c:\somepath\mydriver.c @ 3642]
f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
f71eb6a8 80b91570 00000000 f71eb6e8 00000042 nt!ObpLookupObjectName+0x59b
f71eb6fc 80b0acdc 00000000 00000000 f71eb801 nt!ObOpenObjectByName+0x13e

I am currently trying to replicate the problem using the smbmrx sample
provided in the IFSkit so I have symbols and source :slight_smile: Sorry for hideously
long email, but any help is GREATLY appreciated…

Matt

2

Are you sure that STATUS_SHARING_VIOLATION it returned by redirector itself
and was not propagated from the remote end? If it is propagated from the
remote system I would suspect that first create request got a batch oplock
and the second create request arrives to remote system before batch oplock
was broken by remote system. It is possible that by delaying IRP_MJ_CLOSE
you confuse logic related to sending breaking oplocks to the remote system.

Alexei.

“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Hi,
> I was wondering if anyone has had a similar problem to this one and
> if it was solvable… I am a filter filtering the mrxsmb redirector on XP
> SP1 and using the stream file alternative to IoCancelFileOpen; that is, I
> clone the fileobject and do the CREATE with the cloned object before
sending
> down the “real” CREATE. After creating my cloned FILE_OBJECT, I send down
a
> CLEANUP IRP on it to allow any sharing state to be released, and I hold on
> to my FILE_OBJECT reference. Then I send down the real CREATE. This
works
> great on FAT and NTFS, but when filtering the redirector, I am having
> problems with the real CREATE failing with STATUS_SHARING_VIOLATION,
> apparently because I still have a reference to my clone file object.
> Digging into some assembly, I found the error code to be returned by
> SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like
this:
>
> ChildEBP RetAddr Args to Child
> f71eae60 f81f7da4 820da468 00000000 820da468
> mrxsmb!SmbPseContinueOrdinaryExchange+0x15
> f71eae90 f81ef4e4 00000000 00000028 00000000
> mrxsmb!SmbPseOrdinaryExchange+0x1b7
> f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
> mrxsmb!SmbPseExchangeStart_Create+0x328
> f71eaee8 f81f6d47 820da468 00000005 e1289008
> mrxsmb!SmbPseExchangeStart_default+0xe
> f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
> mrxsmb!SmbCeInitiateExchange+0x29d
> f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
> f71eafa0 f8230557 81eaa488 00000004 e10b2c18
> rdbss!RxCollapseOrCreateSrvOpen+0xf4
> f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48
rdbss!RxCreateFromNetRoot+0x2ba
> f71eb064 f8225920 81eaa488 820ad888 f822e030 rdbss!RxCommonCreate+0x2e0
> f71eb108 f822ec97 f822e030 827dcf00 827dcfb8
rdbss!RxFsdCommonDispatch+0x333
> f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
> f71eb150 80a20812 00000000 017dcf48 8204d9a8
mrxsmb!MRxSmbFsdDispatch+0x132
> f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
> f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
> f71eb510 80a20812 81f64540 827dcf48 81f64540 mydriver!MyDriverCreate+0xe0a
> [c:\somepath\mydriver.c @ 3642]
> f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
> f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
> f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
> f71eb6a8 80b91570 00000000 f71eb6e8 00000042 nt!ObpLookupObjectName+0x59b
> f71eb6fc 80b0acdc 00000000 00000000 f71eb801 nt!ObOpenObjectByName+0x13e
>
>
> I am currently trying to replicate the problem using the smbmrx sample
> provided in the IFSkit so I have symbols and source :slight_smile: Sorry for
hideously
> long email, but any help is GREATLY appreciated…
>
> Matt
>
>
>

3

Alexei,
I am fairly sure, because looking at the I/O on the remote system
everything appears normal.

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Thursday, March 11, 2004 10:02 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Are you sure that STATUS_SHARING_VIOLATION it returned by redirector itself
and was not propagated from the remote end? If it is propagated from the
remote system I would suspect that first create request got a batch oplock
and the second create request arrives to remote system before batch oplock
was broken by remote system. It is possible that by delaying IRP_MJ_CLOSE
you confuse logic related to sending breaking oplocks to the remote system.

Alexei.

“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Hi,
> I was wondering if anyone has had a similar problem to this one and if
> it was solvable… I am a filter filtering the mrxsmb redirector on
> XP
> SP1 and using the stream file alternative to IoCancelFileOpen; that
> is, I clone the fileobject and do the CREATE with the cloned object
> before
sending
> down the “real” CREATE. After creating my cloned FILE_OBJECT, I send
> down
a
> CLEANUP IRP on it to allow any sharing state to be released, and I
> hold on to my FILE_OBJECT reference. Then I send down the real
> CREATE. This
works
> great on FAT and NTFS, but when filtering the redirector, I am having
> problems with the real CREATE failing with STATUS_SHARING_VIOLATION,
> apparently because I still have a reference to my clone file object.
> Digging into some assembly, I found the error code to be returned by
> SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like
this:
>
> ChildEBP RetAddr Args to Child
> f71eae60 f81f7da4 820da468 00000000 820da468
> mrxsmb!SmbPseContinueOrdinaryExchange+0x15
> f71eae90 f81ef4e4 00000000 00000028 00000000
> mrxsmb!SmbPseOrdinaryExchange+0x1b7
> f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
> mrxsmb!SmbPseExchangeStart_Create+0x328
> f71eaee8 f81f6d47 820da468 00000005 e1289008
> mrxsmb!SmbPseExchangeStart_default+0xe
> f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
> mrxsmb!SmbCeInitiateExchange+0x29d
> f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
> f71eafa0 f8230557 81eaa488 00000004 e10b2c18
> rdbss!RxCollapseOrCreateSrvOpen+0xf4
> f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48
rdbss!RxCreateFromNetRoot+0x2ba
> f71eb064 f8225920 81eaa488 820ad888 f822e030
> rdbss!RxCommonCreate+0x2e0
> f71eb108 f822ec97 f822e030 827dcf00 827dcfb8
rdbss!RxFsdCommonDispatch+0x333
> f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
> f71eb150 80a20812 00000000 017dcf48 8204d9a8
mrxsmb!MRxSmbFsdDispatch+0x132
> f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
> f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
> f71eb510 80a20812 81f64540 827dcf48 81f64540
> mydriver!MyDriverCreate+0xe0a [c:\somepath\mydriver.c @ 3642]
> f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
> f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
> f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
> f71eb6a8 80b91570 00000000 f71eb6e8 00000042
> nt!ObpLookupObjectName+0x59b f71eb6fc 80b0acdc 00000000 00000000
> f71eb801 nt!ObOpenObjectByName+0x13e
>
>
> I am currently trying to replicate the problem using the smbmrx sample
> provided in the IFSkit so I have symbols and source :slight_smile: Sorry for
hideously
> long email, but any help is GREATLY appreciated…
>
> Matt
>
>
>

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

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

4

Alexei,
I take that back :slight_smile: I am seeing STATUS_SHARING_VIOLATION on the
remote machine…

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Friday, March 12, 2004 4:31 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Alexei,
I am fairly sure, because looking at the I/O on the remote system
everything appears normal.

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Thursday, March 11, 2004 10:02 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Are you sure that STATUS_SHARING_VIOLATION it returned by redirector itself
and was not propagated from the remote end? If it is propagated from the
remote system I would suspect that first create request got a batch oplock
and the second create request arrives to remote system before batch oplock
was broken by remote system. It is possible that by delaying IRP_MJ_CLOSE
you confuse logic related to sending breaking oplocks to the remote system.

Alexei.

“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Hi,
> I was wondering if anyone has had a similar problem to this one and if
> it was solvable… I am a filter filtering the mrxsmb redirector on
> XP
> SP1 and using the stream file alternative to IoCancelFileOpen; that
> is, I clone the fileobject and do the CREATE with the cloned object
> before
sending
> down the “real” CREATE. After creating my cloned FILE_OBJECT, I send
> down
a
> CLEANUP IRP on it to allow any sharing state to be released, and I
> hold on to my FILE_OBJECT reference. Then I send down the real
> CREATE. This
works
> great on FAT and NTFS, but when filtering the redirector, I am having
> problems with the real CREATE failing with STATUS_SHARING_VIOLATION,
> apparently because I still have a reference to my clone file object.
> Digging into some assembly, I found the error code to be returned by
> SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like
this:
>
> ChildEBP RetAddr Args to Child
> f71eae60 f81f7da4 820da468 00000000 820da468
> mrxsmb!SmbPseContinueOrdinaryExchange+0x15
> f71eae90 f81ef4e4 00000000 00000028 00000000
> mrxsmb!SmbPseOrdinaryExchange+0x1b7
> f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
> mrxsmb!SmbPseExchangeStart_Create+0x328
> f71eaee8 f81f6d47 820da468 00000005 e1289008
> mrxsmb!SmbPseExchangeStart_default+0xe
> f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
> mrxsmb!SmbCeInitiateExchange+0x29d
> f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
> f71eafa0 f8230557 81eaa488 00000004 e10b2c18
> rdbss!RxCollapseOrCreateSrvOpen+0xf4
> f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48
rdbss!RxCreateFromNetRoot+0x2ba
> f71eb064 f8225920 81eaa488 820ad888 f822e030
> rdbss!RxCommonCreate+0x2e0
> f71eb108 f822ec97 f822e030 827dcf00 827dcfb8
rdbss!RxFsdCommonDispatch+0x333
> f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
> f71eb150 80a20812 00000000 017dcf48 8204d9a8
mrxsmb!MRxSmbFsdDispatch+0x132
> f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
> f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
> f71eb510 80a20812 81f64540 827dcf48 81f64540
> mydriver!MyDriverCreate+0xe0a [c:\somepath\mydriver.c @ 3642]
> f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
> f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
> f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
> f71eb6a8 80b91570 00000000 f71eb6e8 00000042
> nt!ObpLookupObjectName+0x59b f71eb6fc 80b0acdc 00000000 00000000
> f71eb801 nt!ObOpenObjectByName+0x13e
>
>
> I am currently trying to replicate the problem using the smbmrx sample
> provided in the IFSkit so I have symbols and source :slight_smile: Sorry for
hideously
> long email, but any help is GREATLY appreciated…
>
> Matt
>
>
>

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

You are currently subscribed to ntfsd as: xxxxx@bitarmor.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@bitarmor.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

5

The problem is that redirector caches lots of requests assuming that the
requestor is going to open the file again very soon. So, I would think your
issue is that redirector is caching your cleanup request, if you filter the
remote system you probably won’t see it go through over there. Hence there
is an open reference to the file.

Two work-arounds I found for this 1) play with the access on the interim FO
and the real FO to get things to work right 2) force the interim FO closed
and retry the real request a few times, few being relative to what you are
trying to accomplish… yeah, it’s ugly but when working with the redirector
anything is fair game.

Good luck,

Pete

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-169835-
xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Thursday, March 11, 2004 2:06 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Hi,
I was wondering if anyone has had a similar problem to this one and
if it was solvable… I am a filter filtering the mrxsmb redirector on XP
SP1 and using the stream file alternative to IoCancelFileOpen; that is, I
clone the fileobject and do the CREATE with the cloned object before
sending
down the “real” CREATE. After creating my cloned FILE_OBJECT, I send down
a
CLEANUP IRP on it to allow any sharing state to be released, and I hold on
to my FILE_OBJECT reference. Then I send down the real CREATE. This
works
great on FAT and NTFS, but when filtering the redirector, I am having
problems with the real CREATE failing with STATUS_SHARING_VIOLATION,
apparently because I still have a reference to my clone file object.
Digging into some assembly, I found the error code to be returned by
SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like
this:

ChildEBP RetAddr Args to Child
f71eae60 f81f7da4 820da468 00000000 820da468
mrxsmb!SmbPseContinueOrdinaryExchange+0x15
f71eae90 f81ef4e4 00000000 00000028 00000000
mrxsmb!SmbPseOrdinaryExchange+0x1b7
f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
mrxsmb!SmbPseExchangeStart_Create+0x328
f71eaee8 f81f6d47 820da468 00000005 e1289008
mrxsmb!SmbPseExchangeStart_default+0xe
f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
mrxsmb!SmbCeInitiateExchange+0x29d
f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
f71eafa0 f8230557 81eaa488 00000004 e10b2c18
rdbss!RxCollapseOrCreateSrvOpen+0xf4
f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48
rdbss!RxCreateFromNetRoot+0x2ba
f71eb064 f8225920 81eaa488 820ad888 f822e030 rdbss!RxCommonCreate+0x2e0
f71eb108 f822ec97 f822e030 827dcf00 827dcfb8
rdbss!RxFsdCommonDispatch+0x333
f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
f71eb150 80a20812 00000000 017dcf48 8204d9a8
mrxsmb!MRxSmbFsdDispatch+0x132
f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
f71eb510 80a20812 81f64540 827dcf48 81f64540 mydriver!MyDriverCreate+0xe0a
[c:\somepath\mydriver.c @ 3642]
f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
f71eb6a8 80b91570 00000000 f71eb6e8 00000042 nt!ObpLookupObjectName+0x59b
f71eb6fc 80b0acdc 00000000 00000000 f71eb801 nt!ObOpenObjectByName+0x13e

I am currently trying to replicate the problem using the smbmrx sample
provided in the IFSkit so I have symbols and source :slight_smile: Sorry for
hideously
long email, but any help is GREATLY appreciated…

Matt

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

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

6

And yes, this caching behavior is because of the oplocks taken on the file.

Pete

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-169905-
xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Friday, March 12, 2004 11:54 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Alexei,
I take that back :slight_smile: I am seeing STATUS_SHARING_VIOLATION on the
remote machine…

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Friday, March 12, 2004 4:31 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Alexei,
I am fairly sure, because looking at the I/O on the remote system
everything appears normal.

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Thursday, March 11, 2004 10:02 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Are you sure that STATUS_SHARING_VIOLATION it returned by redirector
itself
and was not propagated from the remote end? If it is propagated from the
remote system I would suspect that first create request got a batch oplock
and the second create request arrives to remote system before batch oplock
was broken by remote system. It is possible that by delaying IRP_MJ_CLOSE
you confuse logic related to sending breaking oplocks to the remote
system.

Alexei.

“Matthew N. White” wrote in message
> news:xxxxx@ntfsd…
> > Hi,
> > I was wondering if anyone has had a similar problem to this one and if
> > it was solvable… I am a filter filtering the mrxsmb redirector on
> > XP
> > SP1 and using the stream file alternative to IoCancelFileOpen; that
> > is, I clone the fileobject and do the CREATE with the cloned object
> > before
> sending
> > down the “real” CREATE. After creating my cloned FILE_OBJECT, I send
> > down
> a
> > CLEANUP IRP on it to allow any sharing state to be released, and I
> > hold on to my FILE_OBJECT reference. Then I send down the real
> > CREATE. This
> works
> > great on FAT and NTFS, but when filtering the redirector, I am having
> > problems with the real CREATE failing with STATUS_SHARING_VIOLATION,
> > apparently because I still have a reference to my clone file object.
> > Digging into some assembly, I found the error code to be returned by
> > SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like
> this:
> >
> > ChildEBP RetAddr Args to Child
> > f71eae60 f81f7da4 820da468 00000000 820da468
> > mrxsmb!SmbPseContinueOrdinaryExchange+0x15
> > f71eae90 f81ef4e4 00000000 00000028 00000000
> > mrxsmb!SmbPseOrdinaryExchange+0x1b7
> > f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
> > mrxsmb!SmbPseExchangeStart_Create+0x328
> > f71eaee8 f81f6d47 820da468 00000005 e1289008
> > mrxsmb!SmbPseExchangeStart_default+0xe
> > f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
> > mrxsmb!SmbCeInitiateExchange+0x29d
> > f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
> > f71eafa0 f8230557 81eaa488 00000004 e10b2c18
> > rdbss!RxCollapseOrCreateSrvOpen+0xf4
> > f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48
> rdbss!RxCreateFromNetRoot+0x2ba
> > f71eb064 f8225920 81eaa488 820ad888 f822e030
> > rdbss!RxCommonCreate+0x2e0
> > f71eb108 f822ec97 f822e030 827dcf00 827dcfb8
> rdbss!RxFsdCommonDispatch+0x333
> > f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
> > f71eb150 80a20812 00000000 017dcf48 8204d9a8
> mrxsmb!MRxSmbFsdDispatch+0x132
> > f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
> > f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
> > f71eb510 80a20812 81f64540 827dcf48 81f64540
> > mydriver!MyDriverCreate+0xe0a [c:\somepath\mydriver.c @ 3642]
> > f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
> > f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
> > f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
> > f71eb6a8 80b91570 00000000 f71eb6e8 00000042
> > nt!ObpLookupObjectName+0x59b f71eb6fc 80b0acdc 00000000 00000000
> > f71eb801 nt!ObOpenObjectByName+0x13e
> >
> >
> > I am currently trying to replicate the problem using the smbmrx sample
> > provided in the IFSkit so I have symbols and source :slight_smile: Sorry for
> hideously
> > long email, but any help is GREATLY appreciated…
> >
> > Matt
> >
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@bitarmor.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@bitarmor.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@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Pete,
Thanks so much for your help. Anyway, I think this is exactly what
you guys are describing b/c messing around with the share permissions in the
CREATE options makes the problem go away. Ah, this is fun…

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Friday, March 12, 2004 4:58 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

The problem is that redirector caches lots of requests assuming that the
requestor is going to open the file again very soon. So, I would think your
issue is that redirector is caching your cleanup request, if you filter the
remote system you probably won’t see it go through over there. Hence there
is an open reference to the file.

Two work-arounds I found for this 1) play with the access on the interim FO
and the real FO to get things to work right 2) force the interim FO closed
and retry the real request a few times, few being relative to what you are
trying to accomplish… yeah, it’s ugly but when working with the redirector
anything is fair game.

Good luck,

Pete

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-169835-
xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Thursday, March 11, 2004 2:06 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

Hi,
I was wondering if anyone has had a similar problem to this one and
if it was solvable… I am a filter filtering the mrxsmb redirector
on XP
SP1 and using the stream file alternative to IoCancelFileOpen; that
is, I clone the fileobject and do the CREATE with the cloned object
before sending down the “real” CREATE. After creating my cloned
FILE_OBJECT, I send down a CLEANUP IRP on it to allow any sharing
state to be released, and I hold on to my FILE_OBJECT reference. Then
I send down the real CREATE. This works great on FAT and NTFS, but
when filtering the redirector, I am having problems with the real
CREATE failing with STATUS_SHARING_VIOLATION, apparently because I
still have a reference to my clone file object.
Digging into some assembly, I found the error code to be returned by
SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like
this:

ChildEBP RetAddr Args to Child
f71eae60 f81f7da4 820da468 00000000 820da468
mrxsmb!SmbPseContinueOrdinaryExchange+0x15
f71eae90 f81ef4e4 00000000 00000028 00000000
mrxsmb!SmbPseOrdinaryExchange+0x1b7
f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
mrxsmb!SmbPseExchangeStart_Create+0x328
f71eaee8 f81f6d47 820da468 00000005 e1289008
mrxsmb!SmbPseExchangeStart_default+0xe
f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
mrxsmb!SmbCeInitiateExchange+0x29d
f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
f71eafa0 f8230557 81eaa488 00000004 e10b2c18
rdbss!RxCollapseOrCreateSrvOpen+0xf4
f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48
rdbss!RxCreateFromNetRoot+0x2ba
f71eb064 f8225920 81eaa488 820ad888 f822e030
rdbss!RxCommonCreate+0x2e0
f71eb108 f822ec97 f822e030 827dcf00 827dcfb8
rdbss!RxFsdCommonDispatch+0x333
f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
f71eb150 80a20812 00000000 017dcf48 8204d9a8
mrxsmb!MRxSmbFsdDispatch+0x132
f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
f71eb510 80a20812 81f64540 827dcf48 81f64540
mydriver!MyDriverCreate+0xe0a [c:\somepath\mydriver.c @ 3642]
f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
f71eb6a8 80b91570 00000000 f71eb6e8 00000042
nt!ObpLookupObjectName+0x59b f71eb6fc 80b0acdc 00000000 00000000
f71eb801 nt!ObOpenObjectByName+0x13e

I am currently trying to replicate the problem using the smbmrx sample
provided in the IFSkit so I have symbols and source :slight_smile: Sorry for
hideously long email, but any help is GREATLY appreciated…

Matt

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

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.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@bitarmor.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

8

IIRC this feature is called “batch oplock”. So, probably there are ways of
opening the file without the batch oplock semantics. In these cases, the
redirector will not be allowed to maintain the cache for a closed file.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Peter Scott”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, March 13, 2004 12:58 AM
Subject: RE: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
redirector?

>
> The problem is that redirector caches lots of requests assuming that the
> requestor is going to open the file again very soon. So, I would think your
> issue is that redirector is caching your cleanup request, if you filter the
> remote system you probably won’t see it go through over there. Hence there
> is an open reference to the file.
>
> Two work-arounds I found for this 1) play with the access on the interim FO
> and the real FO to get things to work right 2) force the interim FO closed
> and retry the real request a few times, few being relative to what you are
> trying to accomplish… yeah, it’s ugly but when working with the redirector
> anything is fair game.
>
> Good luck,
>
> Pete
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-169835-
> > xxxxx@lists.osr.com] On Behalf Of Matthew N. White
> > Sent: Thursday, March 11, 2004 2:06 PM
> > To: Windows File Systems Devs Interest List
> > Subject: [ntfsd] STATUS_SHARING_VIOLATION while filtering mrxsmb
> > redirector?
> >
> > Hi,
> > I was wondering if anyone has had a similar problem to this one and
> > if it was solvable… I am a filter filtering the mrxsmb redirector on XP
> > SP1 and using the stream file alternative to IoCancelFileOpen; that is, I
> > clone the fileobject and do the CREATE with the cloned object before
> > sending
> > down the “real” CREATE. After creating my cloned FILE_OBJECT, I send down
> > a
> > CLEANUP IRP on it to allow any sharing state to be released, and I hold on
> > to my FILE_OBJECT reference. Then I send down the real CREATE. This
> > works
> > great on FAT and NTFS, but when filtering the redirector, I am having
> > problems with the real CREATE failing with STATUS_SHARING_VIOLATION,
> > apparently because I still have a reference to my clone file object.
> > Digging into some assembly, I found the error code to be returned by
> > SmbPseContinueOrdinaryExchange in mrxsmb, with the stack looking like
> > this:
> >
> > ChildEBP RetAddr Args to Child
> > f71eae60 f81f7da4 820da468 00000000 820da468
> > mrxsmb!SmbPseContinueOrdinaryExchange+0x15
> > f71eae90 f81ef4e4 00000000 00000028 00000000
> > mrxsmb!SmbPseOrdinaryExchange+0x1b7
> > f71eaedc f81f77e4 000da468 81eaa488 f81f6d47
> > mrxsmb!SmbPseExchangeStart_Create+0x328
> > f71eaee8 f81f6d47 820da468 00000005 e1289008
> > mrxsmb!SmbPseExchangeStart_default+0xe
> > f71eaf04 f81f1118 81f42ba8 81eaa508 81eaa488
> > mrxsmb!SmbCeInitiateExchange+0x29d
> > f71eaf4c f8230775 00eaa488 0012019f 81eaa488 mrxsmb!MRxSmbCreate+0x27c
> > f71eafa0 f8230557 81eaa488 00000004 e10b2c18
> > rdbss!RxCollapseOrCreateSrvOpen+0xf4
> > f71eb004 f822ee1b 81eaa488 f71eb050 827dcf48
> > rdbss!RxCreateFromNetRoot+0x2ba
> > f71eb064 f8225920 81eaa488 820ad888 f822e030 rdbss!RxCommonCreate+0x2e0
> > f71eb108 f822ec97 f822e030 827dcf00 827dcfb8
> > rdbss!RxFsdCommonDispatch+0x333
> > f71eb130 f81ea862 8204d9a8 827dcf00 8204d9a8 rdbss!RxFsdDispatch+0xb4
> > f71eb150 80a20812 00000000 017dcf48 8204d9a8
> > mrxsmb!MRxSmbFsdDispatch+0x132
> > f71eb168 80cae110 827dcfd4 827dcff8 00000000 nt!IopfCallDriver+0x4f
> > f71eb18c f70f8518 81f64540 827dcf48 00000001 nt!IovCallDriver+0x9e
> > f71eb510 80a20812 81f64540 827dcf48 81f64540 mydriver!MyDriverCreate+0xe0a
> > [c:\somepath\mydriver.c @ 3642]
> > f71eb528 80cae110 827dcf58 827dcf48 820ad888 nt!IopfCallDriver+0x4f
> > f71eb54c 80b1cd5b 8204d990 80004528 81e53a00 nt!IovCallDriver+0x9e
> > f71eb630 80b96877 8204d9a8 00000000 81e53a50 nt!IopParseDevice+0xb84
> > f71eb6a8 80b91570 00000000 f71eb6e8 00000042 nt!ObpLookupObjectName+0x59b
> > f71eb6fc 80b0acdc 00000000 00000000 f71eb801 nt!ObOpenObjectByName+0x13e
> >
> >
> > I am currently trying to replicate the problem using the smbmrx sample
> > provided in the IFSkit so I have symbols and source :slight_smile: Sorry for
> > hideously
> > long email, but any help is GREATLY appreciated…
> >
> > Matt
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.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@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com