Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CreateFile sharing violation

485 views
Skip to first unread message

Timothy Jewett

unread,
May 21, 2009, 1:23:01 PM5/21/09
to
I have a service that is creating a file with a desired access setting of all
access and a sharing of FILE_SHARE_READ. If the service still has the handle
open and another application tries to read the file (open with generic_read)
I get a sharing violation on the second application.

ProcessMonitor entries:

****** Create from service *********
Date & Time: 5/18/2009 3:36:56 PM
Event Class: File System
Operation: CreateFile
Result: SUCCESS
Path: E:\TIM32\GroupReporting\Release\Logs\GroupReporting.txt
TID: 4368
Duration: 0.0010142
Desired Access: All Access
Disposition: OverwriteIf
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: Read
AllocationSize: 0
OpenResult: Overwritten


****** Read from 2nd app ********

Date & Time: 5/18/2009 3:37:04 PM
Event Class: File System
Operation: CreateFile
Result: SHARING VIOLATION
Path: E:\TIM32\GroupReporting\Release\Logs\GroupReporting.txt
TID: 5412
Duration: 0.0000481
Desired Access: Generic Read
Disposition: Open
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: Read, Write
AllocationSize: n/a

What am I doing wrong with the service ????

--
Timothy Jewett
Jewet...@online.nospam

Remy Lebeau

unread,
May 21, 2009, 1:31:08 PM5/21/09
to

"Timothy Jewett" <jewet...@online.nospam> wrote in message
news:BE0A1BDA-F519-4269...@microsoft.com...

> I have a service that is creating a file with a desired access setting
> of all access and a sharing of FILE_SHARE_READ. If the service
> still has the handle open and another application tries to read the file
> (open with generic_read) I get a sharing violation on the second
> application.

Sounds like the app is not specifying sharing rights that match the access
rights the service used to create the file with. Sharing rights have to
match on both ends.

--
Remy Lebeau (TeamB)


Tim Roberts

unread,
May 22, 2009, 1:14:35 AM5/22/09
to
Timothy Jewett <jewet...@online.nospam> wrote:

>I have a service that is creating a file with a desired access setting of all
>access and a sharing of FILE_SHARE_READ. If the service still has the handle
>open and another application tries to read the file (open with generic_read)
>I get a sharing violation on the second application.

Right. The second open is not specifying FILE_SHARE_DELETE, which means it
cannot co-exist with an open with delete access, and your service asked for
that (since that's included in "all" access).

If your service only needs read and write access, then you should only
specify GENERIC_READ | GENERIC_WRITE. GENERIC_ALL is almost never a good
idea.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

Alexander Grigoriev

unread,
May 22, 2009, 10:09:56 AM5/22/09
to
Are you sure your second app does have permissions to access the file?

"Timothy Jewett" <jewet...@online.nospam> wrote in message
news:BE0A1BDA-F519-4269...@microsoft.com...

Timothy Jewett

unread,
May 26, 2009, 4:22:45 PM5/26/09
to
Tim,
I thought the 2nd parameter was the required access for the file and the
3rd parameter specifing what another open against the file would be allowed ?
If this is not what this is for what is the purpose of the 3rd parameter ?
--
Timothy Jewett
Jewet...@online.nospam

Tim Roberts

unread,
May 27, 2009, 1:11:37 AM5/27/09
to
Timothy Jewett <jewet...@online.nospam> wrote:
>
> I thought the 2nd parameter was the required access for the file and the
>3rd parameter specifing what another open against the file would be allowed ?
>If this is not what this is for what is the purpose of the 3rd parameter ?

You have it exactly right, and that's where the conflict is. For the
"share mode" parameter -- the 3rd parameter -- if you specify
FILE_SHARE_READ, you are saying "I am willing to coexist with other opens
that asked for GENERIC_READ". If you omit FILE_SHARE_READ, you are saying
"I am *NOT* willing to coexist with other opens that asked for
GENERIC_READ."

Your first open specified GENERIC_ALL for the second parameter, which means
you want every access permission there is. That includes read, write, and
delete, among others.

Then, your second open specified FILE_SHARE_READ | FILE_SHARE_WRITE for the
third parameter, which says "I am willing to coexist with any open that
asked for READ and WRITE permission." But, you did not specify
FILE_SHARE_DELETE, and that says "I am *NOT* willing to coexist with
another open that asked for delete permission." Your first open DID ask
for delete permission (that's part of GENERIC_ALL), and so the second open
fails with a sharing violation.

So, you have two choices. You chould change your first open so that the
required access parameter is GENERIC_READ | GENERIC_WRITE. That way, it
matches correctly with your second open, which has FILE_SHARE_READ |
FILE_SHARE_WRITE. I would argue that this is the correct solution.

Alternatively, you should be able to change the share mode on your second
open to FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, but I don't
think that's the right solution.

Timothy Jewett

unread,
May 27, 2009, 9:24:01 AM5/27/09
to
Thanks Tim, the light bulb finally turned on. I'll have to live with the
situation(I need delete if building the file has a problem). The second open
was being done with tools like notepad/textpad.
--
Timothy Jewett
Jewet...@online.nospam
0 new messages