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