Re: shareDenyWrite is not enough
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:arjc84dlsk1mpca1vrp6ur2brul4jdk1n2@4ax.com...
I'm curious why, in all this discussion, nobody has bothered to
single-step into the Open
handler and see what the ::CreateFile arguments are!
Note that there IS no option for ::CreateFile to "deny writes". There is
an option to
PERMIT READS (FILE_SHARE_READ), so the issue is, what is this mysterious
shareDenyWrite
transformed into in the actual CreateFile call? Do we even have a clue
that the code that
does this is correct? Since nobody has bothered to answer that question,
I don't see why
this has gone on for so long!
The call, at the lowest level, should be
CreateFile(filename,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
Until you know that this is what has happened, arguing about the MFC flags
seems
pointless.
And yes, I get what the OP is trying to do: open an existing, inactive
file with multiple
readers and blocking any potential writers. If I wanted to do this, I
would use
CreateFile as above, and if CFile::Open didn't behave as expected, the
first thing I'd do
is make sure that it is properly translated to the above sequence. If it
is, then there
are issues in the operating system. If it isn't, there's a bug in MFC.
joe
That's a good point. I did trace into the MFC code and found modeRead is
mapped to GENERIC_READ and modeDenyWrite is mapped to FILE_SHARE_READ. So
all is well here.
In fact, I could not repro the original issue. I wrote a program called
FileLock (poorly named but still) available at
http://dcsoft.com/private/filelock.zip (MFC source code included, for
VC2008) that lets you specify a file path, open mode, and share mode. I
specified a file called c:\x.bat on my PC, Read mode, and shareDenyWrite.
It opened fine.
I then opened another instance of the app and repeated the above. It was
also opened fine. So the original claim that shareDenyWrite prevented
multiple apps from opening the file did not happen to me.
I also verified that while either only the first, or both the first and
second instances of my app had the file open, I could not edit and save the
file in notepad (notepad gave an error and opened File Save dialog for me to
specify another filename).
So it looks like all is well here.
-- David