STATUS_SHARING_VIOLATION behavior

I have a case where word running on a client machine is saving a doc to a
server (via SRV.sys). I’m seeing different application/srv behavior based on
my filter being involved or not, even though it rejects a create in the same
way. Basically here is the scenario:

App/srv issues a 1ST create file exclusive. Success.
App/srv later issues a 2ND create for the same file shared and gets a
rejected create.
FSD completes the create with STATUS_SHARING_VIOLATION.
App/srv closes the file for the 1ST create.
App/srv then opens the file successfully.

If my filter is the loop
App/srv issues a 1ST create file exclusive. Success.
App/srv later issues a 2ND create for the same file shared and gets a
rejected create.
MY FILTER completes the 2ND create with STATUS_SHARING_VIOLATION. With no
call made to the FSD below.
App/srv issues a 2ND create for the same file shared and gets a rejected
create.
MY FILTER completes the 2ND create with STATUS_SHARING_VIOLATION. With no
call made to the FSD below.
App/srv issues a 2ND create for the same file shared and gets a rejected
create.
MY FILTER completes the 2ND create with STATUS_SHARING_VIOLATION. With no
call made to the FSD below.
App/srv issues a 2ND create for the same file shared and gets a rejected
create.
MY FILTER completes the 2ND create with STATUS_SHARING_VIOLATION. With no
call made to the FSD below.
App/srv issues a 2ND create for the same file shared and gets a rejected
create.
MY FILTER completes the 2ND create with STATUS_SHARING_VIOLATION. With no
call made to the FSD below.
App/srv gives up on trying to open the file and fails the write in the
application.
It eventually close the 1ST create.

It appears that the FSD is notifying App/SRV that the file needs to be
closed. Is this true? If so how can my filter do this.

Thanks,
Ken

Hi Ken,

have you checked the Irp->UserIosb field ? I’ve got the impression that
this field is used privately between LM Client and LM Server, e.g. to share
infos about OpLock states, but unfortunately I havven’t found anybody by
now who could tell me more about it…

hope it helps,
Udo

Thanks Udo,
I thought of that, The FSD returns a zero and I do as well.
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@abg1.siemens.de
Sent: Monday, September 11, 2000 8:39 AM
To: File Systems Developers
Subject: [ntfsd] Re: STATUS_SHARING_VIOLATION behavior

Hi Ken,

have you checked the Irp->UserIosb field ? I’ve got the impression that
this field is used privately between LM Client and LM Server, e.g. to share
infos about OpLock states, but unfortunately I havven’t found anybody by
now who could tell me more about it…

hope it helps,
Udo


You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)