Re: dwShareMode Failure in CreateFile

I suppose that you could create a named mutex where the name of the mutex is
related to the name of the file and an application will try to acquire the
mutex before using the file. Of course, if you're trying to make sure that
no application ever tried to access a file name that instance #1 is using, I
guess you'd have to know more about the usage pattern than I do...

Paul T.

"Fred Harris" <FredHarris@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:790E2819-7491-4D6B-92C6-14F2BF2C277A@xxxxxxxxxxxxxxxx
Paul!

It just hit me like a ton of bricks! Of course, I can open the file
multiples of times by multiple instances of the same app. Its being open
and
closed in a message handler for the Open File Dialog Box! I'm really
sorry
to have put you out on this. It really had me going. Now though, to
solve
the problem of someone doing this I have to figure something out to
prevent
multiple instances of the app from opening the same file. Something along
the line of broadcasting a message to all apps with the same name, or
programatically hiding the file so it doesn't show up in an open file
dialog
box to be opened by another app?

"Paul G. Tobey [eMVP]" wrote:

Yes, those are both valid values. INVALID_HANDLE_VALUE is 0xffffffff.

What filesystem is hosting the file? I opened mine in the RAM filesystem
and, as I said, it worked perfectly, rejecting two programs trying to
access
the same file at the same time.

My guess, again, is that you're not actually opening the same file every
time. What is the full file name string that you're passing to
CreateFile()? Remember that there is *no such thing* as a 'current
directory' in Windows CE, so you *must* specify the full path to your
target
file.

I've tried all three filesystem types to which my CE4.2 device has
access,
RAM filesystem, built-in flash, and PCMCIA and they all do exactly the
right
thing with second instances of applications making the call. The same is
true of a single instance of the application opening the same file
multiple
times. INVALID_HANDLE_VALUE and error 32.

Paul T.

"Fred Harris" <FredHarris@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:17E9D1EA-0400-44B1-B3C6-B2A7E012B3D0@xxxxxxxxxxxxxxxx
Paul,,

With that exact CreateFile() call I posted above I can open as many
instances of my app as I want that accesses the same exact file, and
every
time I open the file I get a valid file handle and a GetLastError() of
183
indicating the file already exists. Here are some real numbers for
you
on
two open attempts...

2747456058
2747718066

Those are valid handle values, I believe. In fact, I know they
are.
The reason I'm doing this exercise is that in an initial field test of
an
app where this is happening I ended up with a corrupted data file. I
didn't
write this app as a multi-user database app, so two different instances
of
the app accessing the same file won't work!

I tried this exact setup on my laptop (Windows XP ) and the second
time
I try to open the same file with that CreateFile() Api call I get
0xFFFFFFFF
for a file handle (INVLAID_HANDLE_VALUE, I think), and a
GetLastError()
of
32, just as you say.

At this point I don't know how to prevent seperates instances of
this
app accidentally opening the same file twice and corrupting the data
file.
I
was counting on a dwShareMode=0 preventing this.

The only thing I can come up with that I'm hoping might work is to
see
if I change that OPEN_ALWAYS to OPEN_EXISTING if that will cause
correct
processing of the functions parameters to kick in cuz they're sure not
working now! At present I just have an 'Open' on the file menu and
OPEN_ALWAYS as that other parameter, figuring that if someone types in
the
name of a new file it will open that OK, and if they execute an
existing
file, that dwShareMode will protect me there. But if I can get
OPEN_EXISTING
to work and that dwShareMode kicks in correctly, then I'll just add a
'Open
New' to the file menu for new files.

The device I'm working on is Juniper Systems, Inc Allegro CX
running
CE.NET version 4.2. Any further thoughts?

Paul G. Tobey [eMVP]" wrote:

Huh? The call is behaving right. The error code, in that case, is
just
indicating whether the file exists or not when you open it. If no one
else
has it open, but the file exists, you'll get that to indicate to you
whether
you opened an existing file or created a new file. You might need
that
information to know whether you should seek to the end of the existing
file
or do something with the existing data or not (if the file didn't
exist).
If you actually try to open the file from two applications at the same
time,
you'll actually get an error, probably 32(decimal), and an invalid
file
handle (I tested this and it works EXACTLY right).

Paul T.

"Fred Harris" <FredHarris@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:36301E4A-9379-4DFA-A6BD-7675784119CE@xxxxxxxxxxxxxxxx
I'm using CreateFile() with eMbedded VC++ 4.0 to open a random
access
file.
According to the Api reference on the function the third parameter
to
the
call is dwShareMode. The docs state that if the parameter is set to
0
there
can't be any sharing of the file and subsequent Open operations on
the
file
will fail. I had counted on this to be so and didn't even test it
untill
I
recently had a file corruption issue in a case where two instances
of
the
same application successfully opened the file. In testing this I
find
I
can
open the same file as many times as I want. Here is the
CreateFile()
call...

hFileData=
CreateFile
(
ed->szFile,
GENERIC_READ|GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
FILE_FLAG_RANDOM_ACCESS,
NULL
);

As you can see the third parameter is zero. If I output hFileData
to a
message box right after the call I get valid file handles on all
instances
of
the app that opens the file. Also, if I output GetrLastError() to a
message
box all I get is '183' which means file already exists, which isn't
much
help. Any thoughts on either the error itself or how I might be
able
to
prevent multiple instances of an app opening the same file. I'll
add
that
this behavior is different from desktop Api as there you'll get
a testable error code in hFile if file already open.








.

Relevant Pages

  • Re: Snow Leopard - Lost File Extensions & Custom Icons
    ... this document with the app that created it' behaviour set differently ... open-with code, ... about double-clicking this file opens it in TextWrangler; ... machine that's based on the creator code, on mine it's the default app ...
    (uk.comp.sys.mac)
  • Re: Fastest way to read data to populate combo controls?
    ... The only real reason to ... So there is a way I can read a closed Excel file directly into the ... and the VB app opens that document. ... but keep the Word app object because I will use it later. ...
    (microsoft.public.vb.general.discussion)
  • Re: Relative Hyperlinks
    ... Word can open MHT files it opens, as they're encoded to let IE and Word know what app they were created in, by default (Check to see ... LINKS to the 2007 Office System ...
    (microsoft.public.word.newusers)
  • Re: dwShareMode Failure in CreateFile
    ... multiples of times by multiple instances of the same app. ... My guess, again, is that you're not actually opening the same file every ... the app that opens the file. ...
    (microsoft.public.windowsce.embedded)
  • Re: Problems with .mpg file association
    ... MPG/MPEG File Association Fix (Restores default associations for MPG/MPEG ... associates with the file type ok - the associated app opens ... open an mpg any way at all until I re-login. ...
    (microsoft.public.windowsxp.general)
Loading