pywin32-bugs Mailing List for Python for Windows Extensions (Page 108)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2004-04-07 05:33:37
|
Bugs item #823967, was opened at 2003-10-15 18:36 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=823967&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Laszlo Dobrontei (ubcsi) Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomxx.dll redirect Initial Comment: In file pythoncom.py (line 6) would be better to find "_d" only in the file part of "win32api.__file__". I had win32api.pyd in a directory, which contained "_d" characters. I this case my application tried to load "pythoncom22_d.dll". ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:33 Message: Logged In: YES user_id=14198 This has since been fixed and checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=823967&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-07 05:31:51
|
Bugs item #841597, was opened at 2003-11-14 05:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841597&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen White (swhite) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] win32com doesn't work with Sun's Java/ActiveX Bridge Initial Comment: Having created an ActiveX/COM object using Sun's Java/ActiveX bridge I found it worked fine in VBA and also using Perl's Win32::OLE - but was disappointed to find it didn't work in Python. >>> import win32com.client >>> o = win32com.client.Dispatch("Simple.Bean") >>> o.Greeting() Traceback (most recent call last): File "<interactive input>", line 1, in ? File "win32com\client\dynamic.py", line 471, in __getattr__ raise pythoncom.com_error, details com_error: (-2147352567, 'Exception occurred.', (0, None, 'java.lang.NullPointerException', None, 0, -2147352567), None) Read/write access to attributes did work, which I found puzzling so I checked the code. It would appear that win32com relies on access to an attribute returning 'ERRORS_BAD_CONTEXT' when it doesn't exist, in which case win32com then tries the equivalent method. Sun's Java/ActiveX bridge isn't returning this error code, so win32com never tries to execute the method. The attached patch causes win32com to operate correctly in this case. I'm not very familiar with COM so I'm not sure if it's Java or win32com at fault here, or if there's a better fix, but this one works for me. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:31 Message: Logged In: YES user_id=14198 What error code does Sun/Jave use? I'd prefer to add that error to the list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841597&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-07 05:30:35
|
Bugs item #858458, was opened at 2003-12-12 06:14 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=858458&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Garth Bushell (garth_42) Assigned to: Nobody/Anonymous (nobody) Summary: CoInitializeSecurity checks obAuthSvc is NULL not Py_None Initial Comment: (Patch attached Below) CoInitializeSecurity checks to see if obAuthSvc is NULL. it should Check to see if it is Equal to Py_None This means that CoInitializeSecurity call is pretty useless! Unless I'm using it wrong as you can only specify the Auth services to be none and not let COM Choose! I'm using like this.. pythoncom.CoInitializeSecurity( None, None, None, pythoncom.RPC_C_AUTHN_LEVEL_CALL, pythoncom.RPC_C_IMP_LEVEL_IMPERSONATE, None, 0x10, #pythoncom.EOAC_DYNAMIC_CLOAKING , None) Patch attached ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:30 Message: Logged In: YES user_id=14198 Thanks - fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=858458&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-07 05:26:36
|
Bugs item #874096, was opened at 2004-01-10 08:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=874096&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Boreham (dboreham) Assigned to: Nobody/Anonymous (nobody) Summary: Race condition with genpy.py and stdout Initial Comment: I've been investigating a problem for a client of mine where the symptoms were that a generated python file in the ...\win32com\gen_py directory had become corrupted. It looked mostly ok, but contained one line of text which was not Python. I tracked that string down to another part of the application, completely unrelated. Upon investigation I believe that the cause is this code in genpy.py: def generate(self, file, is_for_demand = 0): if is_for_demand: self.generate_type = GEN_DEMAND_BASE else: self.generate_type = GEN_FULL self.file = file oldOut = sys.stdout sys.stdout = file try: self.do_generate() finally: sys.stdout = oldOut self.file = None self.progress.Finished() It's redirecting stdout for the generated python file. In the application this happens underneath a call to gencache.EnsureModule(). Unfortunately the application is concurrently executing another thread which is also writing to stdout. The result is that the two sets of output are intermingled. I guess that it would be possible to refactor the code in genpy.py such that it outputs to a file rather than to stdout (the file could be stdout for cases where the code is run as a standalone utility). I see the checkin comment for version 1.30 suggests that this is a known problem: >Also started a move to "print >>" for the generation. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:26 Message: Logged In: YES user_id=14198 Yes, this could happen :) I'd love patches to address this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=874096&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-07 05:25:24
|
Bugs item #906305, was opened at 2004-02-28 12:44 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=906305&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Problems (deadlock) with calling CEnterLeavePython.acquire Initial Comment: PyWndProcHWND in win32gui explicitly calls the acquire method of _celp (a CEnterLeavePython instance) when handling a WM_NCDESTROY message. Unfortunately, if this message was not handled by PyWndProc_Call, _celp.release will already have been called (just prior to dispatching to oldWndProc), setting _celp.released to TRUE. Because released == TRUE, _celp's destructor does not release the GIL, with a deadlock likely to result. (In my case it did result, since the WM_NCDESTROY was produced by a call to win32gui.DestroyWindow). Perhaps released should be set in the acquire method rather than in the constructor? I'm using win32all build 200, Python 2.3.3, and Windows XP. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:25 Message: Logged In: YES user_id=14198 This bug was recently fixed and will be in the next release. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-02-28 14:49 Message: Logged In: YES user_id=86307 I just realized that, even if PyWndProc_Call handles WM_NCDESTROY, there is still likely to be a deadlock. In that case, _celp.acquire (and thus PyGILState_Ensure) will be called twice, first by the constructor and second by the explicit call. The second call will overwrite _celp.state with PyGILState_LOCKED. When _celp's destructor is called, PyGILState_Release will not try to release the GIL even if the first call to PyGILState_Ensure returned PyGILState_UNLOCKED. If I understand correctly, CEnterLeavePython.acquire should probably look like: void acquire(void) { if (released) { state = PyGILState_Ensure(); released = FALSE; } } // also need: CEnterLeavePython() { released = TRUE; acquire(); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=906305&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-07 05:24:40
|
Bugs item #918016, was opened at 2004-03-18 00:47 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918016&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Martijn Ras (headhunter) Assigned to: Nobody/Anonymous (nobody) Summary: Services fail on mapped network drives Initial Comment: 1) Share the root of your drive C. 2) Map the network drive. 3) Create the following three files in the root of your drive C Note: Replace the following in the python script files: <LOCALHOST> with the name of your machine, <SHARE> with the share name you specified in step 1), <MAPPEDDRIVE> with the drive you specified in step2). 4) Run 'python execfile_test.py', it will print "dit is een test" three times, as expected. 5) Install the service 'python execfile_test_server.py install'. 6) Open the services control panel: a) change the logon so the service run under an account that has sufficient rights on the mapped network drive. b) start the service. 7) Open the EventViewer, select the Application log. You'll notice "dit is een test" has been logged twice and the third loggin an IOError 'No such file or directory'. :::::::::::::: config.txt :::::::::::::: config = 'dit is een test' :::::::::::::: execfile_test.py :::::::::::::: config = {} execfile('C:\config.txt', config) print str(config['config']) execfile('\\<LOCALHOST>\<SHARE>\config.txt', config) print str(config['config']) execfile('<MAPPEDDRIVE>:\config.txt', config) print str(config['config']) :::::::::::::: execfile_test_server.py :::::::::::::: import exceptions import os import pywintypes import win32api import win32con import win32event import win32file import win32pipe import win32security import win32service import win32serviceutil class execfile_test_server(win32serviceutil.ServiceFramework): _svc_name_ = 'execfile_test_server' _svc_display_name_ = 'execfile_test_server' def __init__(self, args): win32serviceutil.ServiceFramework.__init__(self, args) self.hWaitStop = win32event.CreateEvent(None, 0, 0, None) self.overlapped = pywintypes.OVERLAPPED() self.overlapped.hEvent = win32event.CreateEvent(None,0,0,None) self.thread_handles = [] def SvcStop(self): self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING) win32event.SetEvent(self.hWaitStop) def SvcDoRun(self): import servicemanager # Write an event log record indicating we have started servicemanager.LogMsg(servicemanager.EVENTLOG_INFORMATION_TYPE, servicemanager.PYS_SERVICE_STARTED, (self._svc_name_, '')) config = {} execfile('C:\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) execfile('\\<LOCALHOST>\<SHAREDFOLDER>\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) execfile('<SHAREDFOLDER>:\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) # Write another event log record we have stopped servicemanager.LogMsg(servicemanager.EVENTLOG_INFORMATION_TYPE, servicemanager.PYS_SERVICE_STOPPED, (self._svc_name_, '')) if __name__=='__main__': win32serviceutil.HandleCommandLine(execfile_test_server) ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2004-03-18 11:46 Message: Logged In: YES user_id=771074 Larry Bates already answered this on the python-win32 mailing list. The drive you mapped exists only for the user you're signed in as. You can use functions from win32net from within the service to check if a mapped drive exists for the user the service is running as, and create it if not. Alternately, since you have access permission for the shared folder, couldn't you just use the full UNC path ? hth Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918016&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-07 05:23:36
|
Bugs item #918108, was opened at 2004-03-18 03:05 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918108&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: memory issues in PyITypeObjects.cpp Initial Comment: Two problems were discovered in PyITypeObjects.cpp dealing with memory allocation. The patch is attached. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:23 Message: Logged In: YES user_id=14198 Fixed - thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918108&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-07 05:20:36
|
Bugs item #925802, was opened at 2004-03-30 15:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925802&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Brown (dagbrown) Assigned to: Nobody/Anonymous (nobody) Summary: Apparent typo in win32popen Initial Comment: In a couple places in the _PyPopen function, I found this: if (mode && _O_TEXT) That looks like a typo: it should be if (mode & _O_TEXT) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:20 Message: Logged In: YES user_id=14198 Thanks - fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925802&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-06 08:48:37
|
Feature Requests item #930298, was opened at 2004-04-06 12:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=930298&group_id=78018 Category: com Group: None Status: Open Priority: 5 Submitted By: Max Belugin (belugin) Assigned to: Nobody/Anonymous (nobody) Summary: need VBArray support Initial Comment: For integration with flashget (http://www.flashget.com/) need VBArray support Test VBCode: Dim params2(5) set flashget=CreateObject("JetCar.Netscape") Dim j for j=0 to 5 params2(j)="http://test.com/"&j next flashget.AddUrlList params2 Test python code: import win32com.client import array flashget = win32com.client.Dispatch("JetCar.Netscape") urls=[ 'http://test.com/1', 'http://test.com/2', 'http://test.com/3', 'http://test.com/4', 'http://test.com/5' ] flashget.AddUrlList(urls) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=930298&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-04-05 01:30:15
|
Bugs item #929490, was opened at 2004-04-05 13:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=929490&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Win2K Priority class definitions missing from win32process Initial Comment: The ABOVE_NORMAL_PRIORITY_CLASS and BELOW_NORMAL_PRIORITY_CLASS flags are missing from win32process, although they are in the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=929490&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-30 13:37:14
|
Bugs item #917702, was opened at 2004-03-17 01:51 Message generated for change (Comment added) made by frnknstn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=917702&group_id=78018 Category: pythonwin Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: dak (dakcalouro) Assigned to: Nobody/Anonymous (nobody) Summary: pywintypes can't find pywintypes23.dll Initial Comment: After installing Python v2.3 and pywin32 build 200 on Windows ME, at startup pythonwin opens a window titled "Python Traceback when executing InitInstance handler". The window contains File "C:\PROGRAMS\PYTHON\Lib\site- packages\Pythonwin\pywin\framework\intpyapp.py", line 163, in InitInstance import interact File "C:\PROGRAMS\PYTHON\Lib\site- packages\Pythonwin\pywin\framework\interact.py", line 26, in ? import winout File "C:\PROGRAMS\PYTHON\Lib\site- packages\Pythonwin\pywin\framework\winout.py", line 26, in ? from pywintypes import UnicodeType File "C:\PROGRAMS\PYTHON\Lib\site-packages\win32 \lib\pywintypes.py", line 55, in ? __import_pywin32_system_module__("pywintypes", globals()) File "C:\PROGRAMS\PYTHON\Lib\site-packages\win32 \lib\pywintypes.py", line 48, in __import_pywin32_system_module__ raise ImportError, "Can not locate " + filename exceptions.ImportError: Can not locate pywintypes23.dll ------------------ end of error window contents I found the file pywintypes23.dll my C:\Programs\Python installation folder (I can't remember which subfolder) and copied it to the folders that seemed likely: C:\Programs\Python\DLLs, C:\WINDOWS\SYSTEM, C:\WINDOWS\SYSTEM32. Restarting pythonwin.exe gave the same error msg. I scanned pywintypes.py for workaround ideas, and copied pywintypes23.dll to C:\WINDOWS. Now pythonwin starts up without error (shows the version & copyright msg and the >>> interpreter prompt). This is OK as a workaround. ---------------------------------------------------------------------- Comment By: Peter Finlayson (frnknstn) Date: 2004-03-30 15:37 Message: Logged In: YES user_id=1009500 I had a similar problem, also with Python v2.3 and pywin32 build 200, but under Win98SE. For me, the pywintypes23.dll was installed to the c:\windows\system directory. I received the same error window. I resolved the problem by adding C:\WINDOWS\SYSTEM to my path in AUTOEXEC.BAT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=917702&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-30 05:21:31
|
Bugs item #925802, was opened at 2004-03-30 05:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925802&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Brown (dagbrown) Assigned to: Nobody/Anonymous (nobody) Summary: Apparent typo in win32popen Initial Comment: In a couple places in the _PyPopen function, I found this: if (mode && _O_TEXT) That looks like a typo: it should be if (mode & _O_TEXT) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925802&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-29 21:02:36
|
Bugs item #925584, was opened at 2004-03-29 20:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925584&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Withnail & I (alphasixty) Assigned to: Nobody/Anonymous (nobody) Summary: PythonService.exe Dr Watson Errors Initial Comment: I am using Tim Golden's WMI module (version 0.5, obtained from http://tgolden.sc.sabren.com/python/wmi.html I have several services that I have written using win32all, and they have been running for several weeks. I want to use wmi functions, but I can only run servicename.exe update If I servicename.exe start I get a window that says: Pythonservice.e.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. Here is the line I added to my service program file: import wmi If I copy all the code from wmi.py and paste it into my service program, no error occurs on startup. It only seems to happen if I import wmi as a module. As soon as I remove "import wmi" from my program the service works again. A Dr. Watson logfile might contain sensitive info about my system, so I cannot really post it here (the computer belongs to my employer). If you need the logfile, I can send it privately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925584&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-18 00:46:28
|
Bugs item #918016, was opened at 2004-03-17 08:47 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918016&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Ras (headhunter) Assigned to: Nobody/Anonymous (nobody) Summary: Services fail on mapped network drives Initial Comment: 1) Share the root of your drive C. 2) Map the network drive. 3) Create the following three files in the root of your drive C Note: Replace the following in the python script files: <LOCALHOST> with the name of your machine, <SHARE> with the share name you specified in step 1), <MAPPEDDRIVE> with the drive you specified in step2). 4) Run 'python execfile_test.py', it will print "dit is een test" three times, as expected. 5) Install the service 'python execfile_test_server.py install'. 6) Open the services control panel: a) change the logon so the service run under an account that has sufficient rights on the mapped network drive. b) start the service. 7) Open the EventViewer, select the Application log. You'll notice "dit is een test" has been logged twice and the third loggin an IOError 'No such file or directory'. :::::::::::::: config.txt :::::::::::::: config = 'dit is een test' :::::::::::::: execfile_test.py :::::::::::::: config = {} execfile('C:\config.txt', config) print str(config['config']) execfile('\\<LOCALHOST>\<SHARE>\config.txt', config) print str(config['config']) execfile('<MAPPEDDRIVE>:\config.txt', config) print str(config['config']) :::::::::::::: execfile_test_server.py :::::::::::::: import exceptions import os import pywintypes import win32api import win32con import win32event import win32file import win32pipe import win32security import win32service import win32serviceutil class execfile_test_server(win32serviceutil.ServiceFramework): _svc_name_ = 'execfile_test_server' _svc_display_name_ = 'execfile_test_server' def __init__(self, args): win32serviceutil.ServiceFramework.__init__(self, args) self.hWaitStop = win32event.CreateEvent(None, 0, 0, None) self.overlapped = pywintypes.OVERLAPPED() self.overlapped.hEvent = win32event.CreateEvent(None,0,0,None) self.thread_handles = [] def SvcStop(self): self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING) win32event.SetEvent(self.hWaitStop) def SvcDoRun(self): import servicemanager # Write an event log record indicating we have started servicemanager.LogMsg(servicemanager.EVENTLOG_INFORMATION_TYPE, servicemanager.PYS_SERVICE_STARTED, (self._svc_name_, '')) config = {} execfile('C:\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) execfile('\\<LOCALHOST>\<SHAREDFOLDER>\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) execfile('<SHAREDFOLDER>:\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) # Write another event log record we have stopped servicemanager.LogMsg(servicemanager.EVENTLOG_INFORMATION_TYPE, servicemanager.PYS_SERVICE_STOPPED, (self._svc_name_, '')) if __name__=='__main__': win32serviceutil.HandleCommandLine(execfile_test_server) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2004-03-17 19:46 Message: Logged In: YES user_id=771074 Larry Bates already answered this on the python-win32 mailing list. The drive you mapped exists only for the user you're signed in as. You can use functions from win32net from within the service to check if a mapped drive exists for the user the service is running as, and create it if not. Alternately, since you have access permission for the shared folder, couldn't you just use the full UNC path ? hth Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918016&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-17 19:29:46
|
Bugs item #918108, was opened at 2004-03-17 09:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918108&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: memory issues in PyITypeObjects.cpp Initial Comment: Two problems were discovered in PyITypeObjects.cpp dealing with memory allocation. The patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918108&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-17 13:47:41
|
Bugs item #918016, was opened at 2004-03-17 13:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918016&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Ras (headhunter) Assigned to: Nobody/Anonymous (nobody) Summary: Services fail on mapped network drives Initial Comment: 1) Share the root of your drive C. 2) Map the network drive. 3) Create the following three files in the root of your drive C Note: Replace the following in the python script files: <LOCALHOST> with the name of your machine, <SHARE> with the share name you specified in step 1), <MAPPEDDRIVE> with the drive you specified in step2). 4) Run 'python execfile_test.py', it will print "dit is een test" three times, as expected. 5) Install the service 'python execfile_test_server.py install'. 6) Open the services control panel: a) change the logon so the service run under an account that has sufficient rights on the mapped network drive. b) start the service. 7) Open the EventViewer, select the Application log. You'll notice "dit is een test" has been logged twice and the third loggin an IOError 'No such file or directory'. :::::::::::::: config.txt :::::::::::::: config = 'dit is een test' :::::::::::::: execfile_test.py :::::::::::::: config = {} execfile('C:\config.txt', config) print str(config['config']) execfile('\\<LOCALHOST>\<SHARE>\config.txt', config) print str(config['config']) execfile('<MAPPEDDRIVE>:\config.txt', config) print str(config['config']) :::::::::::::: execfile_test_server.py :::::::::::::: import exceptions import os import pywintypes import win32api import win32con import win32event import win32file import win32pipe import win32security import win32service import win32serviceutil class execfile_test_server(win32serviceutil.ServiceFramework): _svc_name_ = 'execfile_test_server' _svc_display_name_ = 'execfile_test_server' def __init__(self, args): win32serviceutil.ServiceFramework.__init__(self, args) self.hWaitStop = win32event.CreateEvent(None, 0, 0, None) self.overlapped = pywintypes.OVERLAPPED() self.overlapped.hEvent = win32event.CreateEvent(None,0,0,None) self.thread_handles = [] def SvcStop(self): self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING) win32event.SetEvent(self.hWaitStop) def SvcDoRun(self): import servicemanager # Write an event log record indicating we have started servicemanager.LogMsg(servicemanager.EVENTLOG_INFORMATION_TYPE, servicemanager.PYS_SERVICE_STARTED, (self._svc_name_, '')) config = {} execfile('C:\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) execfile('\\<LOCALHOST>\<SHAREDFOLDER>\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) execfile('<SHAREDFOLDER>:\config.txt', config) msg = str(config['config']) servicemanager.LogInfoMsg(msg) # Write another event log record we have stopped servicemanager.LogMsg(servicemanager.EVENTLOG_INFORMATION_TYPE, servicemanager.PYS_SERVICE_STOPPED, (self._svc_name_, '')) if __name__=='__main__': win32serviceutil.HandleCommandLine(execfile_test_server) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=918016&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-16 23:51:30
|
Bugs item #917702, was opened at 2004-03-16 15:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=917702&group_id=78018 Category: pythonwin Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: dak (dakcalouro) Assigned to: Nobody/Anonymous (nobody) Summary: pywintypes can't find pywintypes23.dll Initial Comment: After installing Python v2.3 and pywin32 build 200 on Windows ME, at startup pythonwin opens a window titled "Python Traceback when executing InitInstance handler". The window contains File "C:\PROGRAMS\PYTHON\Lib\site- packages\Pythonwin\pywin\framework\intpyapp.py", line 163, in InitInstance import interact File "C:\PROGRAMS\PYTHON\Lib\site- packages\Pythonwin\pywin\framework\interact.py", line 26, in ? import winout File "C:\PROGRAMS\PYTHON\Lib\site- packages\Pythonwin\pywin\framework\winout.py", line 26, in ? from pywintypes import UnicodeType File "C:\PROGRAMS\PYTHON\Lib\site-packages\win32 \lib\pywintypes.py", line 55, in ? __import_pywin32_system_module__("pywintypes", globals()) File "C:\PROGRAMS\PYTHON\Lib\site-packages\win32 \lib\pywintypes.py", line 48, in __import_pywin32_system_module__ raise ImportError, "Can not locate " + filename exceptions.ImportError: Can not locate pywintypes23.dll ------------------ end of error window contents I found the file pywintypes23.dll my C:\Programs\Python installation folder (I can't remember which subfolder) and copied it to the folders that seemed likely: C:\Programs\Python\DLLs, C:\WINDOWS\SYSTEM, C:\WINDOWS\SYSTEM32. Restarting pythonwin.exe gave the same error msg. I scanned pywintypes.py for workaround ideas, and copied pywintypes23.dll to C:\WINDOWS. Now pythonwin starts up without error (shows the version & copyright msg and the >>> interpreter prompt). This is OK as a workaround. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=917702&group_id=78018 |
From: Grosch Franz-J. (MPA/DF) <Fra...@te...> - 2004-03-08 10:08:16
|
Hi, Since I did not find it in the bugtracker, I'd like to report a bug for: win32all-163.exe with Python 2.3.3 it is reproducable on W2k, W XP Professional and W 2003 Server Registering PythonService.exe shows the following behaviour. >> C:\Program Files\Python23\Lib\site-packages\win32>PythonService.exe = -register Registering the Python Service Manager... Fatal Python error: PyThreadState_Get: no current thread abnormal program termination >> I wrote a little Service that uses the built in message dll, for = reporting to the event log. The message dll does no longer register correctly. Regards, Franz-Josef Grosch -- Tenovis Comergo - Applications - Kleyerstra=DFe 94 - D- 60326 Frankfurt = - +49 (0)69 7505 6112 |
From: SourceForge.net <no...@so...> - 2004-03-05 12:32:08
|
Patches item #873846, was opened at 2004-01-09 17:58 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873846&group_id=78018 Category: None Group: None Status: Open Resolution: None >Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Mark Hammond (mhammond) Summary: Fix PyTime.Format (null pointer error) Initial Comment: PyTime.Format currently crashes with a null pointer exception on times before 1970. (pywintypes.Time(x) where x < -1) In Patch 808465 I submitted a change to PyTime.Format that used mktime and localtime to generate the day of week and day of year since day of year is not included in the SYSTEMTIME struct. This can crash because if the time is before 1970 (e.g. pywintypes.Time(-10)) then mktime returns -1 and localtime returns NULL. This is a patch that rather does the calculations properly (they are just numeric). I took the code directly from the Python 2.3 datetime module and merged in the required functions. The resulting code is therefore simple and more reliable. ---------------------------------------------------------------------- >Comment By: David Fraser (davidfraser) Date: 2004-03-05 14:25 Message: Logged In: YES user_id=221678 No longer high priority as a fix for the crash has been applied. But still, this is more general code. Should it still be applied? Or linked to the Python 2.3 datetime module? ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-03-02 09:30 Message: Logged In: YES user_id=221678 Changing priority - this should be fixed soon! There is a test to demonstrate it in bug 873847 ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-01-19 16:14 Message: Logged In: YES user_id=221678 fixes a crash, so should be applied soon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873846&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-05 12:28:27
|
Patches item #873847, was opened at 2004-01-09 18:01 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873847&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: add test to catch null pointer error in PyTime.Format Initial Comment: This test will crash Python in versions that don't have the fix for the null pointer in PyTime.Format ---------------------------------------------------------------------- >Comment By: David Fraser (davidfraser) Date: 2004-03-05 14:21 Message: Logged In: YES user_id=221678 This has been applied in CVS, and is in build 200 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873847&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-04 20:23:28
|
Bugs item #910033, was opened at 2004-03-04 19:35 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=910033&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Build 200 doesn't include PythonService.exe Initial Comment: As per the summary. I cannot find pythonservice.exe anywhere in my Python directory. Reverting to build 163 fixed the problem. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2004-03-04 20:17 Message: Logged In: YES user_id=113328 I just noticed the pythonservice.zip file in the download area. Looks like the problem's already known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=910033&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-04 19:42:01
|
Bugs item #910033, was opened at 2004-03-04 19:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=910033&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Build 200 doesn't include PythonService.exe Initial Comment: As per the summary. I cannot find pythonservice.exe anywhere in my Python directory. Reverting to build 163 fixed the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=910033&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-02 07:35:37
|
Patches item #873846, was opened at 2004-01-09 17:58 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873846&group_id=78018 Category: None Group: None Status: Open Resolution: None >Priority: 9 Submitted By: David Fraser (davidfraser) >Assigned to: Mark Hammond (mhammond) Summary: Fix PyTime.Format (null pointer error) Initial Comment: PyTime.Format currently crashes with a null pointer exception on times before 1970. (pywintypes.Time(x) where x < -1) In Patch 808465 I submitted a change to PyTime.Format that used mktime and localtime to generate the day of week and day of year since day of year is not included in the SYSTEMTIME struct. This can crash because if the time is before 1970 (e.g. pywintypes.Time(-10)) then mktime returns -1 and localtime returns NULL. This is a patch that rather does the calculations properly (they are just numeric). I took the code directly from the Python 2.3 datetime module and merged in the required functions. The resulting code is therefore simple and more reliable. ---------------------------------------------------------------------- >Comment By: David Fraser (davidfraser) Date: 2004-03-02 09:30 Message: Logged In: YES user_id=221678 Changing priority - this should be fixed soon! There is a test to demonstrate it in bug 873847 ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-01-19 16:14 Message: Logged In: YES user_id=221678 fixes a crash, so should be applied soon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873846&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-03-01 20:15:17
|
Bugs item #907801, was opened at 2004-03-01 15:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=907801&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David W. Nichols (dwnichols) Assigned to: Nobody/Anonymous (nobody) Summary: failed shortcuts when changed Start Menu Group Initial Comment: When I installed Python 2.3.3, I changed Start Menu Group setting from its default of "Python 2.3" to "Python233". Here's the results from the final install screen: Creating .PTH file C:\Python23\pywin32.pth Copy pythoncom23.dll to C:\WINDOWS\system32 Copy pywintypes23.dll to C:\WINDOWS\system32 Registered: Python.Interpreter Registered: Python.Dictionary -> Software\Python\PythonCore\2.3\Help[None]=None -> Software\Python\PythonCore\2.3\Help\Pythonwin Reference[None]='C: \Python23\Lib\site-packages\PyWin32.chm' Creating directory C: \Python23\Lib\site-packages\win32com\gen_py Failed to create shortcut 'C:\Documents and Settings\All Users\Start Menu\Programs\Python 2.3\PythonWin.lnk' - error 0x80070003 The pywin32 extensions were successfully installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=907801&group_id=78018 |
From: SourceForge.net <no...@so...> - 2004-02-28 03:51:53
|
Bugs item #906305, was opened at 2004-02-27 16:44 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=906305&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Problems (deadlock) with calling CEnterLeavePython.acquire Initial Comment: PyWndProcHWND in win32gui explicitly calls the acquire method of _celp (a CEnterLeavePython instance) when handling a WM_NCDESTROY message. Unfortunately, if this message was not handled by PyWndProc_Call, _celp.release will already have been called (just prior to dispatching to oldWndProc), setting _celp.released to TRUE. Because released == TRUE, _celp's destructor does not release the GIL, with a deadlock likely to result. (In my case it did result, since the WM_NCDESTROY was produced by a call to win32gui.DestroyWindow). Perhaps released should be set in the acquire method rather than in the constructor? I'm using win32all build 200, Python 2.3.3, and Windows XP. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2004-02-27 18:49 Message: Logged In: YES user_id=86307 I just realized that, even if PyWndProc_Call handles WM_NCDESTROY, there is still likely to be a deadlock. In that case, _celp.acquire (and thus PyGILState_Ensure) will be called twice, first by the constructor and second by the explicit call. The second call will overwrite _celp.state with PyGILState_LOCKED. When _celp's destructor is called, PyGILState_Release will not try to release the GIL even if the first call to PyGILState_Ensure returned PyGILState_UNLOCKED. If I understand correctly, CEnterLeavePython.acquire should probably look like: void acquire(void) { if (released) { state = PyGILState_Ensure(); released = FALSE; } } // also need: CEnterLeavePython() { released = TRUE; acquire(); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=906305&group_id=78018 |