Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

_winreg error on open key (64bit) - proper usage of _winreg.DisableReflectionKey

 

 

Python python RSS feed   Index | Next | Previous | View Threaded


randall.walls at gmail

Nov 17, 2009, 10:51 AM

Post #1 of 5 (629 views)
Permalink
_winreg error on open key (64bit) - proper usage of _winreg.DisableReflectionKey

Greetings,

I'm writing a python script to automate creating ODBC connections on a
Windows2008 Server (64bit) platform. I created an ODBC manually (using the
GUI), for the purposes of fleshing out the 'check for existing' section of
the script.

Problem: though I can see the key in regedit
(HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\DRSQL2000_muXXXX), calling an
_winreg.OpenKey returns 'WindowsError: [Error 2] The system cannot find the
file specified'. Googling the error brought up the possibility that this key
is being impacted by registry redirection (
http://mail.python.org/pipermail/python-win32/2009-February/008862.html),
and thus the need to use _winreg.DisableReflectionKey to correct this.

I'm new to using _winreg (but not new to python), and though it sounds
simple, I can't figure out how to properly use _winreg.DisableReflectionKey
to make the _winreg.OpenKey work properly, and there is nearly 0
documentation on how to use _winreg.DisableReflectionKey (though I would be
happy to write something up if I could figure the damned thing out).

any help is appreciated. Has anyone else run into this before? I realize
that Server 2008 is new and that _winreg.DisableReflectionKey was just
added, but I'm still hoping SOMEBODY has run into this before.

Many thanks,

--
Randall Walls
Tyler Technologies, Inc


nick at stinemates

Nov 17, 2009, 11:18 AM

Post #2 of 5 (603 views)
Permalink
Re: _winreg error on open key (64bit) - proper usage of _winreg.DisableReflectionKey [In reply to]

>From _winreg.c:

"Disables registry reflection for 32-bit processes running on a 64-bit OperatingSystem. Will generally raise NotImplemented if executed on a 32-bit Operating System. If the key is not on the reflection list, the function succeeds but has noeffect. Disabling reflection for a key does not affect reflection of any subkeys."

Are there any subkeys which you also need to disable? Parent keys?


On Tue, Nov 17, 2009 at 01:51:12PM -0500, Randall Walls wrote:
> Greetings,
>
> I'm writing a python script to automate creating ODBC connections on a
> Windows2008 Server (64bit) platform. I created an ODBC manually (using the
> GUI), for the purposes of fleshing out the 'check for existing' section of
> the script.
>
> Problem: though I can see the key in regedit
> (HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\DRSQL2000_muXXXX), calling an
> _winreg.OpenKey returns 'WindowsError: [Error 2] The system cannot find the
> file specified'. Googling the error brought up the possibility that this key
> is being impacted by registry redirection (
> http://mail.python.org/pipermail/python-win32/2009-February/008862.html),
> and thus the need to use _winreg.DisableReflectionKey to correct this.
>
> I'm new to using _winreg (but not new to python), and though it sounds
> simple, I can't figure out how to properly use _winreg.DisableReflectionKey
> to make the _winreg.OpenKey work properly, and there is nearly 0
> documentation on how to use _winreg.DisableReflectionKey (though I would be
> happy to write something up if I could figure the damned thing out).
>
> any help is appreciated. Has anyone else run into this before? I realize
> that Server 2008 is new and that _winreg.DisableReflectionKey was just
> added, but I'm still hoping SOMEBODY has run into this before.
>
> Many thanks,
>
> --
> Randall Walls
> Tyler Technologies, Inc

> --
> http://mail.python.org/mailman/listinfo/python-list

--
http://mail.python.org/mailman/listinfo/python-list


randall.walls at gmail

Nov 17, 2009, 11:29 AM

Post #3 of 5 (605 views)
Permalink
Re: _winreg error on open key (64bit) - proper usage of _winreg.DisableReflectionKey [In reply to]

I don't believe so, but it seems like I'm in a catch 22, where I need to
_winreg.OpenKey the key first before I can pass it to
_winreg.DisableReflectionKey, but it doesn't exist, so I can't open it.

I did find out that I can open the key using:
hKey = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, r"SOFTWARE\ODBC\ODBC.INI\
DRSQL2000_mu0100\\", 0, _winreg.KEY_READ | _winreg.KEY_WOW64_64KEY)

The 'trick' was adding _winreg.KEY_WOW64_64KEY, which apparently tells the
system to look in the 64bit key area, and not under the Wow6432Node. That
brings up problem #2, though... I can't seem to CREATE a key in the above
path, and _winreg.CreateKey doesn't accept _winreg.KEY_WOW64_64KEY (in fact
it doesn't accept any options other than key, sub_key). _winreg.CreateKey
does work, it just puts the key in SOFTWARE\Wow6432Node\ODBC\ODBC.INI. So
I'm in a quandry... I'd like to use one or the other, and not have to
account for both.

much obliged

On Tue, Nov 17, 2009 at 2:18 PM, Nick Stinemates <nick [at] stinemates>wrote:

> From _winreg.c:
>
> "Disables registry reflection for 32-bit processes running on a 64-bit
> OperatingSystem. Will generally raise NotImplemented if executed on a 32-bit
> Operating System. If the key is not on the reflection list, the function
> succeeds but has noeffect. Disabling reflection for a key does not affect
> reflection of any subkeys."
>
> Are there any subkeys which you also need to disable? Parent keys?
>
>
> On Tue, Nov 17, 2009 at 01:51:12PM -0500, Randall Walls wrote:
> > Greetings,
> >
> > I'm writing a python script to automate creating ODBC connections on a
> > Windows2008 Server (64bit) platform. I created an ODBC manually (using
> the
> > GUI), for the purposes of fleshing out the 'check for existing' section
> of
> > the script.
> >
> > Problem: though I can see the key in regedit
> > (HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\DRSQL2000_muXXXX), calling an
> > _winreg.OpenKey returns 'WindowsError: [Error 2] The system cannot find
> the
> > file specified'. Googling the error brought up the possibility that this
> key
> > is being impacted by registry redirection (
> > http://mail.python.org/pipermail/python-win32/2009-February/008862.html
> ),
> > and thus the need to use _winreg.DisableReflectionKey to correct this.
> >
> > I'm new to using _winreg (but not new to python), and though it sounds
> > simple, I can't figure out how to properly use
> _winreg.DisableReflectionKey
> > to make the _winreg.OpenKey work properly, and there is nearly 0
> > documentation on how to use _winreg.DisableReflectionKey (though I would
> be
> > happy to write something up if I could figure the damned thing out).
> >
> > any help is appreciated. Has anyone else run into this before? I realize
> > that Server 2008 is new and that _winreg.DisableReflectionKey was just
> > added, but I'm still hoping SOMEBODY has run into this before.
> >
> > Many thanks,
> >
> > --
> > Randall Walls
> > Tyler Technologies, Inc
>
> > --
> > http://mail.python.org/mailman/listinfo/python-list
>
>


--
Randall


skippy.hammond at gmail

Nov 17, 2009, 5:59 PM

Post #4 of 5 (598 views)
Permalink
Re: _winreg error on open key (64bit) - proper usage of _winreg.DisableReflectionKey [In reply to]

On 18/11/2009 6:29 AM, Randall Walls wrote:
> I don't believe so, but it seems like I'm in a catch 22, where I need to
> _winreg.OpenKey the key first before I can pass it to
> _winreg.DisableReflectionKey, but it doesn't exist, so I can't open it.
>
> I did find out that I can open the key using:
> hKey = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, r"SOFTWARE\ODBC\ODBC.INI\
> DRSQL2000_mu0100\\", 0, _winreg.KEY_READ | _winreg.KEY_WOW64_64KEY)
>
> The 'trick' was adding _winreg.KEY_WOW64_64KEY, which apparently tells
> the system to look in the 64bit key area, and not under the Wow6432Node.
> That brings up problem #2, though... I can't seem to CREATE a key in the
> above path, and _winreg.CreateKey doesn't accept _winreg.KEY_WOW64_64KEY
> (in fact it doesn't accept any options other than key, sub_key).
> _winreg.CreateKey does work, it just puts the key in
> SOFTWARE\Wow6432Node\ODBC\ODBC.INI. So I'm in a quandry... I'd like to
> use one or the other, and not have to account for both.

It looks like _winreg needs to be enhanced to make the RegCreateKeyEx
API function available. It can be called via the win32api module of
pywin32, or could also be called via ctypes.

HTH,

Mark
--
http://mail.python.org/mailman/listinfo/python-list


brian.curtin at gmail

Nov 18, 2009, 9:50 AM

Post #5 of 5 (580 views)
Permalink
Re: _winreg error on open key (64bit) - proper usage of _winreg.DisableReflectionKey [In reply to]

On Tue, Nov 17, 2009 at 19:59, Mark Hammond <skippy.hammond [at] gmail>wrote:

> On 18/11/2009 6:29 AM, Randall Walls wrote:
>
>> I don't believe so, but it seems like I'm in a catch 22, where I need to
>> _winreg.OpenKey the key first before I can pass it to
>> _winreg.DisableReflectionKey, but it doesn't exist, so I can't open it.
>>
>> I did find out that I can open the key using:
>> hKey = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE,
>> r"SOFTWARE\ODBC\ODBC.INI\
>> DRSQL2000_mu0100\\", 0, _winreg.KEY_READ | _winreg.KEY_WOW64_64KEY)
>>
>> The 'trick' was adding _winreg.KEY_WOW64_64KEY, which apparently tells
>> the system to look in the 64bit key area, and not under the Wow6432Node.
>> That brings up problem #2, though... I can't seem to CREATE a key in the
>> above path, and _winreg.CreateKey doesn't accept _winreg.KEY_WOW64_64KEY
>> (in fact it doesn't accept any options other than key, sub_key).
>> _winreg.CreateKey does work, it just puts the key in
>> SOFTWARE\Wow6432Node\ODBC\ODBC.INI. So I'm in a quandry... I'd like to
>> use one or the other, and not have to account for both.
>>
>
> It looks like _winreg needs to be enhanced to make the RegCreateKeyEx API
> function available. It can be called via the win32api module of pywin32, or
> could also be called via ctypes.
>
> HTH,
>
> Mark
>

Created http://bugs.python.org/issue7347 and added a patch which I think
will solve the problem moving forward.

Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.