Hi Folks:

I'd like to duplicate a handle to a file mapping.

In order to duplicate such a handle, it must have the
FILE_MAP_COPY access right.

I've never dealt with Windows SECURITY_ATTRIBUTES
before, passing NULL values, or attributes with NULL
descriptors, has usually been good enough.

But apparently not now.

I have to learn about this stuff some time. I hope
this will address some pressing issues I need to resolve
now.

MSDN's page at

http://msdn2.microsoft.com/en-us/library/aa366559.aspx

which talks about FILE_MAP_COPY mentions something called
the SACL. I'm guessing this is needed to set FILE_MAP_COPY.

The file mapping examples in Jeffrey Richter's "Advanced
Windows" have SECURITY_ATTRIBUTES with NULL pointers to
their SECURITY_DESCRIPTOR. I'm thinking it's time to flush
that out.

Now the attribute has a pointer to a security descriptor.

MSDN indicates that the security descriptor's structure
is opaque, and should only be manipulated by functions.

SetSecurityDescriptorSacl() is called to assign an ACL
to the descriptor.

Ok, now I need to setup the ACL.

The description of the ACL structure

Am I on the right track? Is this path eventually going
to lead me to a value in a structure, or a function, where
I can assert FILE_MAP_COPY? Can somebody help me find the
place where I can assert this access right?

Thanks
Larry

"Larry Lindstrom" <nobody@aracnet.com> wrote in message
news:M_ydncX1Pv74RpnanZ2dnUVZ_v6rnZ2d@comcast.com. ..
I had similar problems, PARTICULARLY after switching to Vista. (I couldn't
understand security descriptors, either).

I did not duplicate the handle; instead I had the other processes map to the
same shared object name. When I switched to Vista, I found that my program
could no longer use the object name "Global\myobject".

What I learned was that objects using "Global\..." must have admin rights;
whereas objects using "Local\..." don't need rights, although the programs
must be running in the same session (which threads and programs from
"CreateProcess" do).

I hope this helps.

Jeff.

Jeffrey Adler wrote:
Thanks Jeff:

I'm looking for a method that will allow two processes
to share mappings without naming them.

The more I learn about duplicating mapping handles, the
more I think I may need to abandon my idea, and use names
for the mappings.

Right now I'm in the "Ok, if I name the mappings... Oh
wait, that causes this problem..." stage of analyzing the
task.

I do appreciate your advice.

Larry

"Larry Lindstrom" <nobody@aracnet.com> wrote in message
news:qbOdnXg8g62HoZjanZ2dnUVZ_oOnnZ2d@comcast.com. ..
In my case, I created a name using the process PID of the parent, i.e:

sprintf (shmem_name, "Local\\shmem_%d", GetCurrentProcessId ());

Then either pass the process id or shmem_name to the client. In some cases,
I would create a named pipe (or unnamed pipe with inheritable handle), then
pass the process ID to the client.

I don't think that duplicating a handle of a shared memory object will get
you very far. Simplify, simplify, simplify!

Jeff.

Jeffrey Adler wrote:
Thanks again Jeff:

Picture a tree, each node is paged pack mapping in order
to share the nodes, no files are involved in this "File
mapping" process. Each node represents a row of a database.

Mappings disappear with their owners, so the parent must
build and alter the tree as needed.

Thousands of nodes, now have the child traverse the tree.

Currently the left and right nodes node are handles of
mappings.

To descend the left node. Get the left handle, now
duplicate the handle so it's valid for the child (This
is what I'm struggling to do now), Call MapViewOfFile()
on the duplicated handle, repeat through the tree.

On the way up the resursion, close the view, close
the dupliated handle.

These nodes have text, in shared memory of course,
that are represented in the node by a text length and
a handle. And of course I have code that extracts
them. But the links are just handles.

That sounds simple.

If I now name each of the thousands of nodes, the
primary key from the database is an obvious component
of the name.

So I've unquely identified the nodes, but now a
traversal involves links that are text.

I guess it can work, but it doesn't seem like a
simplification.

I'm still thinking about it. But I think using
handles for the links, if that is even possable, is
the simplest solution.

Jeff, I do appreciate your input. And right now I
may follow your suggestion. But can you see why I'm
looking for an alternative?

Thanks
Larry

On Thu, 04 Oct 2007 13:52:47 -0700, Larry Lindstrom
<nobody@aracnet.com> wrote:

I don't follow what you gain by having so many different mappings. Is
there any reason you can't use just one mapping of a very large size
and allocate all your nodes in there. The left and right links then
would just be offsets into the file mapping shared mem. One process,
creates the file mapping, all others just open it.

Is there any limit on the possible number of nodes?
How big is the text associated with each node?

What are the child processes trying to accomplish as they traverse the
tree?

--
Kevin English

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Larry Lindstrom wrote:
Hi again Jeff:

After further thought, I can use the int64_t database
primary keys for the links. And just build the mapping
name they reference. So that's a little simpler.

Thanks
Larry

Kevin English wrote:
Thanks Kevin:

There is no limit to the number of records in the database
table , which will needs to be represented in the tree.

I'm not copying the whole table into the tree, but each
node does have primary key and some other frequently used
columns from the database. These include text, of varying
length. Mostly personal names.

The concept of allocating a single large mapping is
something I'm unfamiliar with. Can such a mapping contain
class instances? I tend to think in those terms.

This is my first attempt to implement a "Document-oriented
model", something Microsoft mentions in their MDI pages, and
uses in Word, Excel and Internet Explorer.

The parent process, who will own the mapped tree, is the
frame. The parent will start when the use starts the app,
and terminate when the user is finished.

The child processes will have shorter lives, but will
be the ones manipulating the database, and sending the
parent instructions on how the tree needs to be altered
to reflect the current state of the database.

A single large mapping is interesting. But I anticipate
a lot of creation, destruction and alteration of the data.
The mix of different length text strings also sounds like
a complication.

Is there a site that describes using a single large
mapping for this task?

I appreciate you offering this idea.

Thanks
Larry

On Thu, 04 Oct 2007 15:02:10 -0700, Larry Lindstrom
<nobody@aracnet.com> wrote:

but it seems you could be in danger of running out of filemapping
handles anyway. Any idea the limit on the number of these handles.
How do you handle not being able to create a new node because the os
is out of handles?
strings.
Assuming that a 16meg mem area is sufficient,
Create or Open the file mapping object.
MapViewOfFile() from 0 to 16meg.
Now with this 16meg of memory you can allocate and free chunks of it
with your own special alloc() and free() routines. These chunks can
be the nodes of your tree and any of the processes should be able to
allocate and free them as needed. You'll need to protect the accesses
with a mutex or something. Freeing and Allocating this way should be
faster than constantly creating/deleting mapping handles.

If it turns out that the amount of shared mem you need exceeds what
can be mapped at any one time, then things get more complicated but
they are workable.

Hope this helps. In any case good luck.
--
Kevin English

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com