shareDenyWrite is not enough
Alexander
read it simultaneously. The flag shareDenyWrite does the first but not
the second and I'm forced to use shareDenyNone (which works).
Any thoughts?
David Ching
news:6c435000-7beb-4b49...@u6g2000prc.googlegroups.com...
>I want to prevent writing to a file but allow several processes to
> read it simultaneously. The flag shareDenyWrite does the first but not
> the second and I'm forced to use shareDenyNone (which works).
>
shareDenyWrite should not prohibit multiple processes from reading the file.
Perhaps one (or more) of the reader processes is opening the file with
shareDenyRead, thus locking out the other processes?
-- David
Alexander
The answer is no. All process use either shareDenyWrite or nothing.
On Jul 20, 1:56 pm, "David Ching" <d...@remove-this.dcsoft.com> wrote:
> "Alexander" <the44s...@yahoo.com> wrote in message
Anthony Wieser
> Thank you for the reply.
> The answer is no. All process use either shareDenyWrite or nothing.
When you say nothing, do you mean ZERO?
If so, that means share exclusive, denying access to any other open.
Anthony Wieser
Wieser Software Ltd
Norbert Unterberg
Alexander schrieb:
> The answer is no. All process use either shareDenyWrite or nothing.
^^^^^^^
That could be your problem. As far as I remember, not using any shareDeny* flags
opens the file in compatibility mode, which means exclusive access. All the
other processes should use explicitly use shareDenyNothing (or shareDenyWrite if
they care).
Norbert
Tom Serface
Perhaps that why it doesn't work as expected.
Also, could you show your open code so that we could see if there is
something else going on.
Tom
"Alexander" <the4...@yahoo.com> wrote in message
news:6c435000-7beb-4b49...@u6g2000prc.googlegroups.com...
Tom Serface
read mode. That could well be the problem .
Tom
"Norbert Unterberg" <nunte...@newsgroups.nospam> wrote in message
news:eqeAK3m6...@TK2MSFTNGP04.phx.gbl...
Alexander
are allowed... which is weird because it means that in order to allow
shared read I need shareDenyNone... unless shareDenyWrite authorizes
shared reading as a side effect which is bizarre.
Ok, guys. I'm confused. Here is the data:
1. The file is not created by these processes (it is guaranteed to
exist beforehand) and it is never updated.
2. I want all processes to be able to read it simultaneously.
3. This is a text file and all processes use the class CStdioFile to
handle it.
4. Which are the flags (or lack of) that allow simultenous read and
lock _everything_ else out?
Thank you all.
On Jul 20, 3:39 pm, "Anthony Wieser" <newsgroups-sanss...@wieser-
software.com> wrote:
> "Alexander" <the44s...@yahoo.com> wrote in message
Alexander Grigoriev
NOT use DenyWrite, if you want one process to write to the file at the same
time.
"Alexander" <the4...@yahoo.com> wrote in message
news:6c435000-7beb-4b49...@u6g2000prc.googlegroups.com...
Tom Serface
and if any of them are opening it in compatibility mode or with any other
access type (like modeRead) you will run into these problems.
Tom
"Alexander" <the4...@yahoo.com> wrote in message
news:3943299e-d6bb-4115...@x36g2000prg.googlegroups.com...
Alexander
I still don't understand why this is a problem for shared reads.
On Jul 21, 4:55 am, "Tom Serface" <tom.nos...@camaswood.com> wrote:
> I bet you need EVERY process trying to access the file to use shareDenyWrite
> and if any of them are opening it in compatibility mode or with any other
> access type (like modeRead) you will run into these problems.
>
> Tom
>
Tom Serface
with the shareDenyWrite will not likely do anything (except make it more
readable).
I'm running out of ideas. I've been able to do this sort of thing before
with my programs without any problems so I know it is possible.
Tom
"Alexander" <the4...@yahoo.com> wrote in message
news:60b38ae2-bd6e-4b3f...@v21g2000pro.googlegroups.com...
Victor
Victor
Please, check it in all processes you are currecntly using.
Victor.
"Alexander" wrote:
> > >news:daf6776b-f790-46d2...@p25g2000pri.googlegroups.com....
Alexander
this same code:
CStdioFile fIn;
if( fIn.Open( csPath, CFile::modeRead | CFile::shareDenyNone ) )
{
...
}
That code works but, naturally, it allows shared write which is what I
want to prevent.
If shareDenyNone is taken out, shared read is not allowed.
Victor
The correct ones should have been:
modeRead | modeWrite | modeCreate (and modeNoTruncate as optional)
+
shareDenyWrite
In this case all other Open operations might be successful ONLY with the
flags
modeRead | shareDenyNone
Note also, that if the process created this file exits, then it must set
attributes of this file as "Read Only", otherwise any other process will be
able to write to it.
Victor
"Alexander" wrote:
> There is very little mystery, I'm afraid. Here it is. All threads use
> this same code:
>
> CStdioFile fIn;
>
> if( fIn.Open( csPath, CFile::modeRead | CFile::shareDenyNone ) )
> {
> ...
> }
>
> That code works but, naturally, it allows shared write which is what I
> want to prevent.
>
> If shareDenyNone is taken out, shared read is not allowed.
>
>
> On Jul 22, 1:57 am, Victor <Vic...@discussions.microsoft.com> wrote:
> > Could you show your exact code you are using to open this file?
> > Please, check it in all processes you are currecntly using.
> >
> > Victor.
> >
> >
> >
> > "Alexander" wrote:
> > > Yep. All processes had those two flags shareDenyWrite and modeRead.
> >
> > > I still don't understand why this is a problem for shared reads.
> >
> > > On Jul 21, 4:55 am, "Tom Serface" <tom.nos...@camaswood.com> wrote:
> > > > I bet you need EVERY process trying to access the file to use shareDenyWrite
> > > > and if any of them are opening it in compatibility mode or with any other
> > > > access type (like modeRead) you will run into these problems.
> >
> > > > Tom
> >
> > > > "Alexander" <the44s...@yahoo.com> wrote in message
> >
> > > >news:3943299e-d6bb-4115...@x36g2000prg.googlegroups.com....
> > > > That was my conclusion. No flags implies neither shared read or write
> > > > are allowed... which is weird because it means that in order to allow
> > > > shared read I need shareDenyNone... unless shareDenyWrite authorizes
> > > > shared reading as a side effect which is bizarre.
> >
> > > > Ok, guys. I'm confused. Here is the data:
> >
> > > > 1. The file is not created by these processes (it is guaranteed to
> > > > exist beforehand) and it is never updated.
> > > > 2. I want all processes to be able to read it simultaneously.
> > > > 3. This is a text file and all processes use the class CStdioFile to
> > > > handle it.
> > > > 4. Which are the flags (or lack of) that allow simultenous read and
> > > > lock _everything_ else out?
> >
> > > > Thank you all.
> >
> > > > On Jul 20, 3:39 pm, "Anthony Wieser" <newsgroups-sanss...@wieser-
> >
> > > > software.com> wrote:
> > > > > "Alexander" <the44s...@yahoo.com> wrote in message
> >
> > > > >news:daf6776b-f790-46d2...@p25g2000pri.googlegroups.com....
> >
> > > > > > Thank you for the reply.
> > > > > > The answer is no. All process use either shareDenyWrite or nothing.
> >
> > > > > When you say nothing, do you mean ZERO?
> >
> > > > > If so, that means share exclusive, denying access to any other open..
Alexander
is created by another program at a different time and it has no
bearing on the issue at hand.
Consider that the flags I posted (modeRead, shareDenyNone) allow
shared reads while modeRead alone doesn't. Therefore, the problem is
simply how to allow shared reads while disallowing shared writes.
I don't want to disallow shared writes in order to block another
process. None of the process will try to write to this file. I'm just
trying to prevent accidental writing to this file by _unknown_parties_
while my processes are reading it. In short, I'm trying to forsee the
unforseeable and I thought it should be a simple issue of setting the
right flags... it doesn't seem so, though.
David Ching
> The file was created with modeWrite and modeCreate. However, this file
> is created by another program at a different time and it has no
> bearing on the issue at hand.
The writer program is the one that should do:
if( fIn.Open( csPath, CFile::modeWrite | CFile::shareDenyWrite ) )
{
...
}
to make sure it is the only process that can write to the file! But this
says nothing about reading, so multiple files can read this file while it is
being written to. Isn't this what you want?
Thanks,
David
Alexander Grigoriev
shared writes, only one process will be able to open the file for writing,
no other process will be able to open the file for writing AND reading. If
you allow shared writes, all processes will be able to open the file for
reading AND writing. If you want exclusive write access, use LockFileEx.
There is no way to allow writing to a file based on trusted/untrusted
process. Only on basis of account-based access control.
ANother way would be to use DuplicateHandle, when a writer opens the file in
exclusive mode, and then hands the duplicates of the handle (with read-only
access) to its brethren. The handle would need to be opened in overlapped
mode, and you cannot use stdio to work with those.
Yet another way would be to use a service to access the file. The client
processes would request reading and writing to it.
"Alexander" <the4...@yahoo.com> wrote in message
news:03400894-db1f-4a7a...@m3g2000hsc.googlegroups.com...
Alexander Grigoriev
All readers SHOULD allow shared writes and reads (shareDenyNone). A writer
should allow shared reads (shareDenyWrite).
"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:uCVOLPA7...@TK2MSFTNGP03.phx.gbl...
Alexander
1. No thread writes to the file. Writing is not an issue.
2. Several threads read the file at the same time.
The problem is that I found that the only way to allow several threads
to read the file is by using shareDenyNone. In particular:
1. If I don't use shareDenyNone, multiple reads are not allowed.
2. If I use shareDenyWrite, multiple reads are not allowed.
Solution? Use shareDenyNone _which_ does not make sense when all you
want is to allow shared reads.
On Jul 22, 10:26 pm, "David Ching" <d...@remove-this.dcsoft.com>
wrote:
> "Alexander" <the44s...@yahoo.com> wrote in message
Alexander Grigoriev
"Alexander" <the4...@yahoo.com> wrote in message
news:9eeea132-fdb9-4469...@p25g2000hsf.googlegroups.com...
Alexander
CStdioFile fIn;
if( fIn.Open( csPath, CFile::modeRead | CFile::shareDenyNone ) )
{
...
}
That code works.
If shareDenyNone is taken out, shared read is not allowed.
On Jul 23, 1:06 am, "Alexander Grigoriev" <al...@earthlink.net> wrote:
> How are you opening the files for read?
>
Joseph M. Newcomer
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
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Alexander Grigoriev
"Alexander" <the4...@yahoo.com> wrote in message
news:db1f608b-bb80-403d...@j22g2000hsf.googlegroups.com...
David Ching
news:arjc84dlsk1mpca1v...@4ax.com...
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
Alexander
lack of verbal dexterity. His words "open an existing, inactive file
with multiple readers and blocking any potential writers" is precisely
the issue.
David. Thank you for taking the time to put together a test project.
The idea that modeDenyWrite is mapped to FILE_SHARE_READ is strangely
counterintuitive but that was my first thought too. It didn't work for
me but since you have verified that it indeed works, I will take (yet)
another closer look at the code.
Thanks again to everyone that has taken the time to help me out.
On Jul 23, 2:08 pm, "David Ching" <d...@remove-this.dcsoft.com> wrote:
> "Joseph M. Newcomer" <newco...@flounder.com> wrote in messagenews:arjc84dlsk1mpca1v...@4ax.com...
> FileLock (poorly named but still) available athttp://dcsoft.com/private/filelock.zip(MFC source code included, for
Joseph M. Newcomer
since I'm having a major server reconfiguration done here (S2008 and virtual servers, plus
mirrored replication). I don't even try to do this sort of thing; I hire someone to do it
for me, so I was going to have some dead time. But since you've already run the test, I
don't have to. So it looks like the problem lies somewhere else.
I'd suggest the process monitor (www.sysinternals.com) or the more primitive file monitor
and have the OP check that what is claimed is indeed what is happening, and that no one
else has the file open.
joe