8 Mar
2005
8 Mar
'05
11:10 p.m.
Thomas Weidenmueller schrieb:
This doesn't sound right, but the current implemention of key objects
uses this way.
I see two ways to solve the wrong referencing problem. The first one is,
we create the key object and reference it again. One reference is for
holding the key object in the parent key structure valid. The second
reference is for the caller (ObFindObject..) and he could do what he
want with it. The problem is, the first reference is never removed and
it is not possible to dereference (delete) the parent. The other way is
a special data structur between the parent key and the child keys. This
structure has an internal reference count, which is incremented when a
child key is created and decremented when a key is deleted. The create
or delete operation occurs only if the hive is looked. The creating or
deleting of this data structur has nothing to do with the real reference
count of the object. It is always triggered by the create (parse) or
delete operation.
- Hartmut
They look for
an existing sub key object. If one is found, the parse routine reference
this object and return it. But this is not correct. The parse routine
should only use and reference this existing object, if the reference
count is greater than zero.
This doesn't sound right, the reference count should never be zero
because then the object should be deleted, which means accessing it
would be dangerous. The object in any case needs to be removed from
the list before it gets deleted.
My idea is to
split the data for the key object and the key object
itself. The parsing routine creates the data only once, but it creates
for each request a seperate key object.
I don't really understand the advantage of this. For file systems it's
obvious because these objects represent data streams with different
offsets, ... But i don't really understand how it could be useful for
registry key objects.