Sharing violation between CFile Open and CreateFile.
ChrisAtABB
One program uses CFile to open, write, read to verify and close the
file, adding data about every 30 secs. The second program uses
CreateFile and ReadFile to read the content of the file (about every
hour).
The CFile usage is to open with CFile::modeReadWrite and
CFile::shareDenyWrite
The CreateFile usage is GENERIC_READ, FILE_SHARE_READ.
When the 2nd program gets to the file first the CFile open causes a
MFC sharing violation exception.
What changes to the share mode should I select to allow both programs
to share the file?
Joseph M. Newcomer
Program 2 opens the file allowing shared reading (but not writing)
Is the answer not obvious? Program 1 cannot open the program for writing if anyone else
has it open in a mode that does not allow shared writing, which you have explicitly stated
is exactly what you are doing!
Note, by the way, the the behavior of the file, if you opened it for both shared reading
and shared writing, is undefined if the first program opens it, appends to it, and closes
it while the second program is reading it. You might get the new data, you might not, or
you might get part of it. There are no specifications as to what will actually happen.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
>Thank you for your quick response. That's the way I had it originally.
>I had FILE_SHARE_READ | FILE_SHARE_WRITE but when I had this the mfc program
>gave me a file not found error when they clashed, so I changed it and got the sharing violation.
>I was wondering if I needed to say explicitly to the mfc open that I do want file read sharing.
>It does not actually matter if we don't get all the new data on a particular read because
>eventually the writing program will move on to a new file name and the old one will then
>remain permanently closed and we will get the lot.
You have to indicate that you are willling to share reading and writing at both opens.
The problem is that the specification is "undefined". That is, you MIGHT get the data,
you might NOT get the data, but you could also see only PART of the data, which can lead
to erroneous results.
I have successfully used CreateFile with FILE_SHARE_READ | FILE_SHARE_WRITE, but I have
never tried to mix this with CFile::Open or other open styles, so unless you know what
they are using for the flags, there is no way to predict what is actually happening. If I
were trying to determine what was going on, I'd single-step into the CFile::Open until I
got to the CreateFile and see what flags it was using.
Note that if you open the file with FILE_SHARE_READ then no other handle can be created
that wants write access.
joe
ChrisAtABB
> I do not answer private email. You wrote:
>
> >Thank you for your quick response. That's the way I had it originally.
> >I had FILE_SHARE_READ | FILE_SHARE_WRITE but when I had this the mfc program
> >gave me a file not found error when they clashed, so I changed it and got the sharing violation.
> >I was wondering if I needed to say explicitly to the mfc open that I do want file read sharing.
> >It does not actually matter if we don't get all the new data on a particular read because
> >eventually the writing program will move on to a new file name and the old one will then
> >remain permanently closed and we will get the lot.
>
> You have to indicate that you are willling to share reading and writing at both opens.
>
> The problem is that the specification is "undefined". That is, you MIGHT get the data,
> you might NOT get the data, but you could also see only PART of the data, which can lead
> to erroneous results.
>
> I have successfully used CreateFile with FILE_SHARE_READ | FILE_SHARE_WRITE, but I have
> never tried to mix this with CFile::Open or other open styles, so unless you know what
> they are using for the flags, there is no way to predict what is actually happening. If I
> were trying to determine what was going on, I'd single-step into the CFile::Open until I
> got to the CreateFile and see what flags it was using.
>
> Note that if you open the file with FILE_SHARE_READ then no other handle can be created
> that wants write access.
> joe
>
>
>
>
>
>
> >Program 1 opens the file in read/write mode
>
> >Program 2 opens the file allowing shared reading (but not writing)
>
> >Is the answer not obvious? Program 1 cannot open the program for writing if anyone else
> >has it open in a mode that does not allow shared writing, which you have explicitly stated
> >is exactly what you are doing!
>
> >Note, by the way, the the behavior of the file, if you opened it for both shared reading
> >and shared writing, is undefined if the first program opens it, appends to it, and closes
> >it while the second program is reading it. You might get the new data, you might not, or
> >you might get part of it. There are no specifications as to what will actually happen.
> > joe
>
>
> >>I have 2 programs accessing the same file on a Windows CE 5.0 machine.
> >>One program uses CFile to open, write, read to verify and close the
> >>file, adding data about every 30 secs. The second program uses
> >>CreateFile and ReadFile to read the content of the file (about every
> >>hour).
>
> >>The CFile usage is to open with CFile::modeReadWrite and
> >>CFile::shareDenyWrite
>
> >>The CreateFile usage is GENERIC_READ, FILE_SHARE_READ.
>
> >>When the 2nd program gets to the file first the CFile open causes a
> >>MFC sharing violation exception.
>
> >>What changes to the share mode should I select to allow both programs
> >>to share the file?
> >Joseph M. Newcomer [MVP]
> >Web:http://www.flounder.com
> >MVP Tips:http://www.flounder.com/mvp_tips.htm
>
> Joseph M. Newcomer [MVP]
> Web:http://www.flounder.com
> MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide quoted text -
>
> - Show quoted text -
Sorry - didn't mean to use the wrong response. I think that as I get
the unexpected result and you say that the behaviour is undefined I
will create a mutex using the file name as the mutex name then they
should be OK.
Joseph M. Newcomer
which would be the correct approach.
joe
email: newc...@flounder.com
ChrisAtABB
>
> >> - Show quoted text -
>
> >Sorry - didn't mean to use the wrong response. I think that as I get
> >the unexpected result and you say that the behaviour is undefined I
> >will create a mutex using the file name as the mutex name then they
> >should be OK.
>
> Joseph M. Newcomer [MVP]
> email: newco...@flounder.com
> Web:http://www.flounder.com
> MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide quoted text -
>
> - Show quoted text -
My original problem is that the program storing the data which uses
mfc returns a file not found error when it attempts to open the file
that has already been opened by the other program. The LockFileEx
requires an open file handle which is why I opted for the Mutex
because I thought that way I could exclude the other program before
opening the file.
Joseph M. Newcomer
****
The basic problem is that you are opening the file in the incorrect mode in one of the two
open operations. You must open BOTH handles for read-write-shared access before even
considering what to do.
The mutex will significantly slow down your performance, and as such should not be used.
Also, there are interesting problems with naming your mutex; what would you call it?
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com