From Ross.Boylan at ucsf.edu Tue Dec 4 16:48:42 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Tue, 4 Dec 2018 21:48:42 +0000 Subject: [python-win32] COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7 In-Reply-To: References: Message-ID: Sorry: previous message went out before complete. Terminal: Z:\FahyGroup\Ross Boylan\Wk devel>py BSTImport.py --debug aatmpt_bst In main. Attempting to register. Args = ['BSTImport.py', '--debug'] And then it just sits there. ^C at the terminal does not interrupt it, though I can kill the python process. Searching in the registry does not indicate any of the keys associated with my class. How do I solve this, or at least debug it? The main application is in 32 bit Access 2010, although the system is 64 bit Win 7. When I discovered I couldn't open the relevant libraries (esp DAO) from 64 bit python 3.6 I installed 32 bit python 3.7. I can use it as a client application, but wanted to make it a server. BSTImport.py includes import pdb, traceback import atexit, csv, sys import pythoncom, win32com.client from win32com.server.exception import COMException from win32com.client import constants from win32com.server.register import UseCommandLine TmpTable = "aatmpt_bst" # table to import csv into print(TmpTable) class BSTImport: # COM Support _public_methods_ = ['Fred'] _reg_clsid_ = "{050321C2-9B99-4444-B5E9-B636DFD94C4D}" _reg_desc_ = "BST Test Com Server in Python 32 bit" _reg_progid_ = "Fahy.BST" def Fred(self, name, obj): return "Hey {}; I'm Fred. I mess with {}.".format(name, TmpTable) # other stuff only relevant as a client if __name__ == "__main__": print("In main. Attempting to register.\nArgs = {}".format(sys.argv)) UseCommandLine(BSTImport) print("I think I'm done.") From Ross.Boylan at ucsf.edu Tue Dec 4 20:12:27 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Wed, 5 Dec 2018 01:12:27 +0000 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: References: , Message-ID: I tried using my 64 bit Python 3.6 and ran into the same problem. Tracing through with pdb, the following line seems to be where it hung up: > c:\program files\python36\lib\site-packages\win32com\server\register.py(419)RegisterClasses() -> moduleName = os.path.splitext(win32api.FindFiles(sys.argv[0])[0][8])[0] (Pdb) n Is this some kind of string conversion issue? My installation is borked? Manual debugging statements show sys.argv[0] is 'BSTImport.py'. win32api.FindFiles('BSTImport.py') in a python 3.7 shell (32 bit) hangs. I think I installed pywin32 via pip. Ross ________________________________________ From: Boylan, Ross Sent: Tuesday, December 4, 2018 1:48 PM To: python-win32 at python.org Subject: Re: COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7 Sorry: previous message went out before complete. Terminal: Z:\FahyGroup\Ross Boylan\Wk devel>py BSTImport.py --debug aatmpt_bst In main. Attempting to register. Args = ['BSTImport.py', '--debug'] And then it just sits there. ^C at the terminal does not interrupt it, though I can kill the python process. Searching in the registry does not indicate any of the keys associated with my class. How do I solve this, or at least debug it? The main application is in 32 bit Access 2010, although the system is 64 bit Win 7. When I discovered I couldn't open the relevant libraries (esp DAO) from 64 bit python 3.6 I installed 32 bit python 3.7. I can use it as a client application, but wanted to make it a server. BSTImport.py includes import pdb, traceback import atexit, csv, sys import pythoncom, win32com.client from win32com.server.exception import COMException from win32com.client import constants from win32com.server.register import UseCommandLine TmpTable = "aatmpt_bst" # table to import csv into print(TmpTable) class BSTImport: # COM Support _public_methods_ = ['Fred'] _reg_clsid_ = "{050321C2-9B99-4444-B5E9-B636DFD94C4D}" _reg_desc_ = "BST Test Com Server in Python 32 bit" _reg_progid_ = "Fahy.BST" def Fred(self, name, obj): return "Hey {}; I'm Fred. I mess with {}.".format(name, TmpTable) # other stuff only relevant as a client if __name__ == "__main__": print("In main. Attempting to register.\nArgs = {}".format(sys.argv)) UseCommandLine(BSTImport) print("I think I'm done.") From Ross.Boylan at ucsf.edu Tue Dec 4 23:20:50 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Wed, 5 Dec 2018 04:20:50 +0000 Subject: [python-win32] win32api.FindFiles hangs In-Reply-To: References: , , Message-ID: win32api.FindFiles() works when the argument is "*" or "*.py". It works, in the sense of returning an empty list, if the argument is a random name not present in the directory. But it fails with "BSTImport.py", as well as the name of every file in the directory that I've tried. ________________________________________ From: Boylan, Ross Sent: Tuesday, December 4, 2018 5:12 PM To: python-win32 at python.org Subject: win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) I tried using my 64 bit Python 3.6 and ran into the same problem. Tracing through with pdb, the following line seems to be where it hung up: > c:\program files\python36\lib\site-packages\win32com\server\register.py(419)RegisterClasses() -> moduleName = os.path.splitext(win32api.FindFiles(sys.argv[0])[0][8])[0] (Pdb) n Is this some kind of string conversion issue? My installation is borked? Manual debugging statements show sys.argv[0] is 'BSTImport.py'. win32api.FindFiles('BSTImport.py') in a python 3.7 shell (32 bit) hangs. I think I installed pywin32 via pip. From ckkart at hoc.net Wed Dec 5 09:48:21 2018 From: ckkart at hoc.net (ckkart at hoc.net) Date: Wed, 05 Dec 2018 11:48:21 -0300 Subject: [python-win32] win32api.FindFiles hangs In-Reply-To: References: , , Message-ID: Works just fine on my windows7 machine with python2.7 64bit and pywin32-221 It yields results for both existing and non existing files. Christian Am 2018-12-05 01:20, schrieb Ross.Boylan at ucsf.edu: > win32api.FindFiles() works when the argument is "*" or "*.py". It > works, in the sense of returning an empty list, if the argument is a > random name not present in the directory. But it fails with > "BSTImport.py", as well as the name of every file in the directory > that I've tried. > ________________________________________ > From: Boylan, Ross > Sent: Tuesday, December 4, 2018 5:12 PM > To: python-win32 at python.org > Subject: win32api.FindFiles hangs (was COM registration hangs up: 32 > bit Python 3.7 on 64 bit Win 7) > > I tried using my 64 bit Python 3.6 and ran into the same problem. > Tracing through with pdb, the following line seems to be where it hung > up: >> c:\program >> files\python36\lib\site-packages\win32com\server\register.py(419)RegisterClasses() > -> moduleName = > os.path.splitext(win32api.FindFiles(sys.argv[0])[0][8])[0] > (Pdb) n > > Is this some kind of string conversion issue? My installation is > borked? > Manual debugging statements show sys.argv[0] is 'BSTImport.py'. > > win32api.FindFiles('BSTImport.py') > in a python 3.7 shell (32 bit) hangs. > > I think I installed pywin32 via pip. > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 From timr at probo.com Wed Dec 5 17:21:33 2018 From: timr at probo.com (Tim Roberts) Date: Wed, 5 Dec 2018 14:21:33 -0800 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: References: Message-ID: <59a1ccc0-0b5a-603b-c486-271484244754@probo.com> Boylan, Ross wrote: > > Is this some kind of string conversion issue? My installation is borked? > Manual debugging statements show sys.argv[0] is 'BSTImport.py'. > > win32api.FindFiles('BSTImport.py') > in a python 3.7 shell (32 bit) hangs. That's quite bizarre.? The code for win32api.FindFiles is straightforward.? Is this a special directory, like a net share or something?? If you ask for *.py, is BSTImport.py in the list you get back? Do you code in C?? You might code up a trivial C app to run a FindFirstFile/FindNextFile loop with the same parameters to see if the same thing happens.? Of course, I'm not sure what the next step would be, whether that worked or failed. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From Ross.Boylan at ucsf.edu Wed Dec 5 14:00:50 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Wed, 5 Dec 2018 19:00:50 +0000 Subject: [python-win32] win32api.FindFiles hangs In-Reply-To: References: , , , Message-ID: The problem doesn't seem to be python-specific; it appears the underlying FindNext function in the Windows API just keeps returning the same file name instead of moving on. In VBA in Access 2010: Public Sub test2(pattern) Dim fn As String fn = Dir$(pattern) Do While fn <> "" Debug.Print fn fn = Dir$() Loop End Sub When I execute with test2("Z:BSTImport.py") this loops, apparently forever, with each iteration returning BSTImport.py. If I give it *.py as the pattern it prints 2 files (correctly) and exits. I assume the first call to Dir$ does FindFirst and the later ones do FindNext. Using the complete path name doesn't help. This seems both bizarre and a sign that my installation of Windows (not python for windows) is pretty messed up. Ross ________________________________________ From: python-win32 on behalf of ckkart at hoc.net Sent: Wednesday, December 5, 2018 6:48:21 AM To: python-win32 at python.org Subject: Re: [python-win32] win32api.FindFiles hangs Works just fine on my windows7 machine with python2.7 64bit and pywin32-221 It yields results for both existing and non existing files. Christian Am 2018-12-05 01:20, schrieb Ross.Boylan at ucsf.edu: > win32api.FindFiles() works when the argument is "*" or "*.py". It > works, in the sense of returning an empty list, if the argument is a > random name not present in the directory. But it fails with > "BSTImport.py", as well as the name of every file in the directory > that I've tried. > ________________________________________ > From: Boylan, Ross > Sent: Tuesday, December 4, 2018 5:12 PM > To: python-win32 at python.org > Subject: win32api.FindFiles hangs (was COM registration hangs up: 32 > bit Python 3.7 on 64 bit Win 7) > > I tried using my 64 bit Python 3.6 and ran into the same problem. > Tracing through with pdb, the following line seems to be where it hung > up: >> c:\program >> files\python36\lib\site-packages\win32com\server\register.py(419)RegisterClasses() > -> moduleName = > os.path.splitext(win32api.FindFiles(sys.argv[0])[0][8])[0] > (Pdb) n > > Is this some kind of string conversion issue? My installation is > borked? > Manual debugging statements show sys.argv[0] is 'BSTImport.py'. > > win32api.FindFiles('BSTImport.py') > in a python 3.7 shell (32 bit) hangs. > > I think I installed pywin32 via pip. > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 From Ross.Boylan at ucsf.edu Wed Dec 5 20:40:56 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Thu, 6 Dec 2018 01:40:56 +0000 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: <59a1ccc0-0b5a-603b-c486-271484244754@probo.com> References: , <59a1ccc0-0b5a-603b-c486-271484244754@probo.com> Message-ID: Yes, the directory is a net share. On a local hard drive I do not experience this problem. If I ask for *.py I get a list back that includes the file. If I ask for "BSTI*" I get back a list of 1 element, the file. But if I ask for "BSTImport.py" it hangs. My experiments with Dir$() in Visual Basic , reported earlier, strongly suggest the problem is that Windows FindNextFile function simply keeps returning the file name forever. I've reported this to the people running the server, though it certainly could be a problem on my local machine. I code in C, but don't have a development environment handy. Hence the test in VBA. Ross ________________________________________ From: python-win32 on behalf of Tim Roberts Sent: Wednesday, December 5, 2018 2:21:33 PM To: python-win32 at python.org Subject: Re: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) Boylan, Ross wrote: > > Is this some kind of string conversion issue? My installation is borked? > Manual debugging statements show sys.argv[0] is 'BSTImport.py'. > > win32api.FindFiles('BSTImport.py') > in a python 3.7 shell (32 bit) hangs. That's quite bizarre. The code for win32api.FindFiles is straightforward. Is this a special directory, like a net share or something? If you ask for *.py, is BSTImport.py in the list you get back? Do you code in C? You might code up a trivial C app to run a FindFirstFile/FindNextFile loop with the same parameters to see if the same thing happens. Of course, I'm not sure what the next step would be, whether that worked or failed. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 From Jim at JC-Bell.com Thu Dec 6 05:44:05 2018 From: Jim at JC-Bell.com (Jim Bell) Date: Thu, 6 Dec 2018 04:44:05 -0600 Subject: [python-win32] win32api.FindFiles hangs In-Reply-To: References: Message-ID: <6ebf3111-d6f0-6d6b-c0d9-3d83caf3247b@JC-Bell.com> Maybe it's not your installation of Windows that's messed up, but just a third party driver. Or someone has mis-configured something on the server. This net share Z: drive: what's the technology / software that's behind it? Is it a standard Windows share, or a third-party driver? (If it's a standard Windows share, is it a Microsoft server doing the sharing?) On 2018-12-05 1:00 PM, Boylan, Ross wrote: > The problem doesn't seem to be python-specific; it appears the underlying FindNext function in the Windows API just keeps returning the same file name instead of moving on. > > ... > This seems both bizarre and a sign that my installation of Windows (not python for windows) is pretty messed up. > > Ross > > ________________________________________ > From: python-win32 on behalf of ckkart at hoc.net > Sent: Wednesday, December 5, 2018 6:48:21 AM > To: python-win32 at python.org > Subject: Re: [python-win32] win32api.FindFiles hangs > > Works just fine on my windows7 machine with python2.7 64bit and > pywin32-221 > It yields results for both existing and non existing files. > > Christian > > Am 2018-12-05 01:20, schrieb Ross.Boylan at ucsf.edu: >> win32api.FindFiles() works when the argument is "*" or "*.py". It >> works, in the sense of returning an empty list, if the argument is a >> random name not present in the directory. But it fails with >> "BSTImport.py", as well as the name of every file in the directory >> that I've tried. >> ________________________________________ >> From: Boylan, Ross >> Sent: Tuesday, December 4, 2018 5:12 PM >> To: python-win32 at python.org >> Subject: win32api.FindFiles hangs (was COM registration hangs up: 32 >> bit Python 3.7 on 64 bit Win 7) >> >> I tried using my 64 bit Python 3.6 and ran into the same problem. >> Tracing through with pdb, the following line seems to be where it hung >> up: >>> c:\program >>> files\python36\lib\site-packages\win32com\server\register.py(419)RegisterClasses() >> -> moduleName = >> os.path.splitext(win32api.FindFiles(sys.argv[0])[0][8])[0] >> (Pdb) n >> >> Is this some kind of string conversion issue? My installation is >> borked? >> Manual debugging statements show sys.argv[0] is 'BSTImport.py'. >> >> win32api.FindFiles('BSTImport.py') >> in a python 3.7 shell (32 bit) hangs. >> >> I think I installed pywin32 via pip. >> _______________________________________________ >> python-win32 mailing list >> python-win32 at python.org >> https://mail.python.org/mailman/listinfo/python-win32 > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > From timr at probo.com Thu Dec 6 13:05:05 2018 From: timr at probo.com (Tim Roberts) Date: Thu, 6 Dec 2018 10:05:05 -0800 Subject: [python-win32] win32api.FindFiles hangs In-Reply-To: <6ebf3111-d6f0-6d6b-c0d9-3d83caf3247b@JC-Bell.com> References: <6ebf3111-d6f0-6d6b-c0d9-3d83caf3247b@JC-Bell.com> Message-ID: Jim Bell wrote: > Maybe it's not your installation of Windows that's messed up, but just > a third party driver. Or someone has mis-configured something on the > server. > > This net share Z: drive: what's the technology / software that's > behind it? Is it a standard Windows share, or a third-party driver? > (If it's a standard Windows share, is it a Microsoft server doing the > sharing?) Yes, this is the right direction to go.? Some NFS implementations, for example, are far less robust than one would really like for the corporate environment.? You might also try temporarily disabling your virus scanner and see if that alters things. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From paolo_bonatti at yahoo.com Mon Dec 10 15:00:17 2018 From: paolo_bonatti at yahoo.com (paolo bonatti) Date: Mon, 10 Dec 2018 20:00:17 +0000 (UTC) Subject: [python-win32] How to obtain printer HANDLE as int in Python References: <229308141.2957133.1544472017662.ref@mail.yahoo.com> Message-ID: <229308141.2957133.1544472017662@mail.yahoo.com> Hi all I'm trying to print PDF documents with pdfix sdk utilizing win32print. This PDF library requires printer HANDLE value as int directly not as a PyObject.? Is there any way to obtain printer HANDLE value in Python code?(attached is a sample) Thanks Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PrintPage copy.py Type: text/x-python-script Size: 2226 bytes Desc: not available URL: From timr at probo.com Mon Dec 10 16:49:24 2018 From: timr at probo.com (Tim Roberts) Date: Mon, 10 Dec 2018 13:49:24 -0800 Subject: [python-win32] How to obtain printer HANDLE as int in Python In-Reply-To: <229308141.2957133.1544472017662@mail.yahoo.com> References: <229308141.2957133.1544472017662.ref@mail.yahoo.com> <229308141.2957133.1544472017662@mail.yahoo.com> Message-ID: paolo bonatti via python-win32 wrote: > I'm trying to print PDF documents with pdfix sdk utilizing win32print. > This PDF library requires printer HANDLE value as int directly not as > a PyObject. > > Is there any way to obtain printer HANDLE value in Python code? > (attached is a sample) > hDC.CreatePrinterDC (win32print.GetDefaultPrinter ()) If that is getting you what you need, then ??? win32print.OpenPrinter( win32print.GetDefaultPrinter() ) will get you the handle to that printer. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From Ross.Boylan at ucsf.edu Tue Dec 11 21:10:36 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Wed, 12 Dec 2018 02:10:36 +0000 Subject: [python-win32] Initial setup and COM debugging issues. Message-ID: The documentation I've found, including Mark's book, advises that I should register COM servers with --debug and use the Trace Collector Debugging Tool on the PythonWin Tools Menu. I can run IDLE, but it has no Tools menu or anything that looks relevant. So I think something else is intended. I can also launch a shell running python, but it has no menus. Additionally, I don't have access to any of the docs from the Windows start menu except for the ability to browse any module interface, though the files are on my computer. So I think my installation is missing some pieces. I installed the standard Windows version of Python from python.org and used pip to install pywin32. There are a number of different pythons installed on the system. Searching suggested the invoked tool was win32traceutil.py; I tried to launch it, but it failed because it had a Python 2 print statement. TraceCollector.py says it is a win32traceutil like utility, so I tried that: C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\pythonwin\pywin\tools>py TraceCollector.py Traceback (most recent call last): File "TraceCollector.py", line 66, in MakeOutputWindow() File "TraceCollector.py", line 54, in MakeOutputWindow outputWindow = WindowOutput(title, title) File "TraceCollector.py", line 31, in __init__ winout.WindowOutput.__init__(*(self,)+args) File "C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\Pythonwin\pywin\framework\winout.py", line 332, in __init__ self.SetIdleHandler() File "C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\Pythonwin\pywin\framework\winout.py", line 373, in SetIdleHandler win32ui.GetApp().AddIdleHandler(self.QueueIdleHandler) AttributeError: 'PyCWinApp' object has no attribute 'AddIdleHandler' That python3.7 is 32 bit, like the COM server I'm trying to debug. Running on 64 bit Win7. Suggestions? Thanks, Ross From drentha at gmail.com Mon Dec 17 20:20:03 2018 From: drentha at gmail.com (Anrik Drenth) Date: Tue, 18 Dec 2018 14:20:03 +1300 Subject: [python-win32] python win32com.client; reverse engineer sql server timestamp Message-ID: I'm looking for the mapping table / logic that will render sql server timestamp values as win32com.client does. I'm currently importing a text file into Access. The text file contains a column with a timestamp value which has been extracted from sql server. The values for the (Access String 50) column look something like " 0x000000000189CF01". Using VBA I want to convert these to the exact same value that win32com creates. In python (sample code below) the timestamp value is stored as an 8 byte, bytearray. Which then gets interpreted by Access. Below is a sample of how the sql server timestamp value is stored in Access: *SQL Server (Timestamp) | Access (Text 50)* 0x000000000189CF01 | 003F49 0x000000000189D001 | 003F69 0x0000000001B54DFF | 003F6D 0x0000000001F74701 | 003F4E 0x000000000189C003 | 003F70 So it tries to do a mapping, sometimes 1 to 1, sometimes not as page 5 of the below link demonstrates https://scripts.sil.org/cms/scripts/render_download.php?format=file&media_id=UnicodeWord&filename=unicodeissuesinword97-2000.pdf I'd appreciate it if anyone has logic or a link to the mapping tables. *Sample Python code * MSAccessconnect = 'Driver={Microsoft Access Driver (*.mdb)};Dbq=test.mdb;' SQLServerconnect = '[ODBC;Driver=SQL Server;SERVER=server1;Database=test;UID=%s;PWD=%s]' %('user', 'pass') strsql = "SELECT * FROM %s.%s;" % (SQLServerconnect, "sqltesttable") print strsql from win32com.client import Dispatch oConn = Dispatch('ADODB.Connection') oConn.ConnectionString = MSAccessconnect oConn.Open() oRS = Dispatch('ADODB.RecordSet') oRS.ActiveConnection = oConn oRS.Open(strsql) while not oRS.EOF: print oRS.Fields.Item("Stamp").Value The text displayed is ??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Tue Dec 18 01:37:29 2018 From: timr at probo.com (Tim Roberts) Date: Mon, 17 Dec 2018 22:37:29 -0800 Subject: [python-win32] python win32com.client; reverse engineer sql server timestamp In-Reply-To: References: Message-ID: On Dec 17, 2018, at 5:20 PM, Anrik Drenth wrote: > > I'm looking for the mapping table / logic that will render sql server timestamp values as win32com.client does. OK, then why did you not tell us what the win32com.client does? > I'm currently importing a text file into Access. The text file contains a column with a timestamp value which has been extracted from sql server. The values for the (Access String 50) column look something like "0x000000000189CF01". That's a 32-bit integer. You need to be storing this as a 32-bit integer, not as a string. Or, best of all, as an Access date/time datatype. Exactly which data type in the SQL Server column? How was the text file generated? In virtually every case, SQL Server will export date and time columns as date time strings (that is, "2018-12-17". How did you get a hex representation? > Using VBA I want to convert these to the exact same value that win32com creates. > > In python (sample code below) the timestamp value is stored as an 8 byte, bytearray. Which then gets interpreted by Access. Which version of Python are you using? You are taking binary data and shoving it through a Unicode-to-ASCII conversion. That produces garbage. That's not a string. It's an integer. > Below is a sample of how the sql server timestamp value is stored in Access: > > SQL Server (Timestamp) | Access (Text 50) 0x000000000189CF01 | 003F49 0x000000000189D001 | 003F69 0x0000000001B54DFF | 003F6D 0x0000000001F74701 | 003F4E 0x000000000189C003 | 003F70 > So it tries to do a mapping, sometimes 1 to 1, sometimes not as page 5 of the below link demonstrates Right. You're producing garbage. The "3F" in there is the "?" character, which means "this character does not exist in the current 8-bit code page". It's not a Unicode string, don't try to treat it like one. ? Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ross.Boylan at ucsf.edu Tue Dec 18 14:50:13 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Tue, 18 Dec 2018 19:50:13 +0000 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: References: , <59a1ccc0-0b5a-603b-c486-271484244754@probo.com>, Message-ID: BTW, I installed Visual Studio and wrote a little C++ program that exercised FindNextFile. It failed in exactly the same way (returns same filename forever if on a network drive and search spec has the exact file name), but only when run from the original machine. This is only one of many signs that the machine (not PyWin) is messed up; we're getting a replacement. Thanks for your help. Ross P.S. Does anyone know why the python com code is doing a Dir() when it already has the exact file name? ________________________________________ From: Boylan, Ross Sent: Wednesday, December 5, 2018 5:40:56 PM To: Tim Roberts; python-win32 at python.org Subject: Re: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) Yes, the directory is a net share. On a local hard drive I do not experience this problem. If I ask for *.py I get a list back that includes the file. If I ask for "BSTI*" I get back a list of 1 element, the file. But if I ask for "BSTImport.py" it hangs. My experiments with Dir$() in Visual Basic , reported earlier, strongly suggest the problem is that Windows FindNextFile function simply keeps returning the file name forever. I've reported this to the people running the server, though it certainly could be a problem on my local machine. I code in C, but don't have a development environment handy. Hence the test in VBA. Ross ________________________________________ From: python-win32 on behalf of Tim Roberts Sent: Wednesday, December 5, 2018 2:21:33 PM To: python-win32 at python.org Subject: Re: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) Boylan, Ross wrote: > > Is this some kind of string conversion issue? My installation is borked? > Manual debugging statements show sys.argv[0] is 'BSTImport.py'. > > win32api.FindFiles('BSTImport.py') > in a python 3.7 shell (32 bit) hangs. That's quite bizarre. The code for win32api.FindFiles is straightforward. Is this a special directory, like a net share or something? If you ask for *.py, is BSTImport.py in the list you get back? Do you code in C? You might code up a trivial C app to run a FindFirstFile/FindNextFile loop with the same parameters to see if the same thing happens. Of course, I'm not sure what the next step would be, whether that worked or failed. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 From Ross.Boylan at ucsf.edu Tue Dec 18 14:58:28 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Tue, 18 Dec 2018 19:58:28 +0000 Subject: [python-win32] Initial setup and COM debugging issues. In-Reply-To: References: , Message-ID: pywin32 is installed just for me, but python itself is installed for all users. I have C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\pythonwin\Pythonwin.exe but when I try to run it (double-click or command prompt in that directory) I get The application can not locate win32ui.pyd (or Python) (126 That file is in the same folder as Pythonwin.exe. Searching turned up some suggestions this is a 32 vs 64 bit problem; everything should be 32 bit (though 64 bit OS) but I'm not sure how to check. The system itself definitely has both 32 and 64 bit pythons installed. Ross ________________________________________ From: python-win32 on behalf of Dennis Lee Bieber Sent: Wednesday, December 12, 2018 11:19:46 AM To: python-win32 at python.org Subject: Re: [python-win32] Initial setup and COM debugging issues. On Wed, 12 Dec 2018 02:10:36 +0000, "Boylan, Ross" declaimed the following: > >So I think my installation is missing some pieces. I installed the standard Windows version of Python from python.org and used pip to install pywin32. There are a number of different pythons installed on the system. > I've always installed ActiveState builds, which include pywin32/win32py (I think the name has changed over its history). To my knowledge PythonWin IDE is included as part of pywin32. >Searching suggested the invoked tool was win32traceutil.py; I tried to launch it, but it failed because it had a Python 2 print statement. TraceCollector.py says it is a win32traceutil like utility, so I tried that: >C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\pythonwin\pywin\tools>py TraceCollector.py >Traceback (most recent call last): I'm guessing you installed Python for single user, given that path. Did you try running the pythonwin executable. Note that the documentation which you trimmed actually states "... for PythonWin" -- which could imply that it is trying to interface with the (expected) pythonwin IDE process -- something you don't have active. I believe all the tools in .../pywin/tools are meant to be invoked by PythonWin itself. PS C:\Users\Wulfraed> Get-ChildItem -Path c:\ -Recurse -Name -Filter "*pythonwin*" Python27\Lib\site-packages\pythonwin Python27\Lib\site-packages\pythonwin\Pythonwin.exe Python35\Lib\site-packages\pythonwin Python35\Lib\site-packages\pythonwin\Pythonwin.exe {Yes, a bit behind -- ActiveState, after all, has to wait for python.org releases before they can start building and testing for their release -- and 3.6, last I looked, is just the core; 3.5 includes a massive number of third party packages} -- Wulfraed Dennis Lee Bieber AF6VN wlfraed at ix.netcom.com HTTP://wlfraed.home.netcom.com/ _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 From timr at probo.com Wed Dec 19 02:27:49 2018 From: timr at probo.com (Tim Roberts) Date: Tue, 18 Dec 2018 23:27:49 -0800 Subject: [python-win32] python win32com.client; reverse engineer sql server timestamp In-Reply-To: References: Message-ID: On Dec 18, 2018, at 1:05 PM, Anrik Drenth wrote: > > Couple of good insights there. Would you have example python code that shows the Unicode-to-ASCII conversion in action? > > So 0x000000000189CF01 to 003F49 > > The current code is written in Python 2.7, its selecting the data from SQL Server and writing it into Access 97. > As Access 97 is somewhat dated we want to get rid of this code and hand responsibility back to the client. > > The sql server timestamp field is a rowid. It was used back in the day under the mistaken assumption it was a datetime field. It is not, subsequently the field exists but has never been used. Aha. Here's my alternate theory, then. I'll bet that field in the Access table is declared as "AutoNumber". In that case, Access would be assigning its own unique row number to the field, totally ignoring the incoming field from SQLServer. That would make a certain amount of sense, but you'd have to look at the other values in that field to be sure. > We still have to re-produce the same exact same value in the field on the off chance it is used by the clients system. Don't you have the code that originally created those fields? It is absolutely pointless for us to guess how this was done. ? Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc at mclaveau.com Wed Dec 19 03:32:24 2018 From: mc at mclaveau.com (mc@mclaveau) Date: Wed, 19 Dec 2018 09:32:24 +0100 Subject: [python-win32] Initial setup and COM debugging issues. In-Reply-To: References: Message-ID: <942d3e22-b662-930b-79c5-ae8625b226d3@mclaveau.com> Hi! During the installation of python, did you check well to add Python in the PATH? This option is at the very bottom of the frame, and not very visible. @-salutations -- Le 18/12/2018 ? 20:58, Boylan, Ross a ?crit?: > pywin32 is installed just for me, but python itself is installed for all users. > I have C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\pythonwin\Pythonwin.exe > but when I try to run it (double-click or command prompt in that directory) I get > The application can not locate win32ui.pyd (or Python) (126 > That file is in the same folder as Pythonwin.exe. > > Searching turned up some suggestions this is a 32 vs 64 bit problem; everything should be 32 bit (though 64 bit OS) but I'm not sure how to check. The system itself definitely has both 32 and 64 bit pythons installed. > > Ross > > ________________________________________ > From: python-win32 on behalf of Dennis Lee Bieber > Sent: Wednesday, December 12, 2018 11:19:46 AM > To: python-win32 at python.org > Subject: Re: [python-win32] Initial setup and COM debugging issues. > > On Wed, 12 Dec 2018 02:10:36 +0000, "Boylan, Ross" > declaimed the following: > >> So I think my installation is missing some pieces. I installed the standard Windows version of Python from python.org and used pip to install pywin32. There are a number of different pythons installed on the system. >> > I've always installed ActiveState builds, which include pywin32/win32py > (I think the name has changed over its history). To my knowledge PythonWin > IDE is included as part of pywin32. > >> Searching suggested the invoked tool was win32traceutil.py; I tried to launch it, but it failed because it had a Python 2 print statement. TraceCollector.py says it is a win32traceutil like utility, so I tried that: >> C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\pythonwin\pywin\tools>py TraceCollector.py >> Traceback (most recent call last): > I'm guessing you installed Python for single user, given that path. Did > you try running the pythonwin executable. Note that the documentation which > you trimmed actually states "... for PythonWin" -- which could imply that > it is trying to interface with the (expected) pythonwin IDE process -- > something you don't have active. > > I believe all the tools in .../pywin/tools are meant to be invoked by > PythonWin itself. > > PS C:\Users\Wulfraed> Get-ChildItem -Path c:\ -Recurse -Name -Filter > "*pythonwin*" > Python27\Lib\site-packages\pythonwin > Python27\Lib\site-packages\pythonwin\Pythonwin.exe > Python35\Lib\site-packages\pythonwin > Python35\Lib\site-packages\pythonwin\Pythonwin.exe > > {Yes, a bit behind -- ActiveState, after all, has to wait for python.org > releases before they can start building and testing for their release -- > and 3.6, last I looked, is just the core; 3.5 includes a massive number of > third party packages} > > > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfraed at ix.netcom.com HTTP://wlfraed.home.netcom.com/ > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: C:\Users\CLAVEAU\AppData\Roaming\Thunderbird\signatures\sign-styloplume.GIF Type: image/gif Size: 9129 bytes Desc: not available URL: From Ross.Boylan at ucsf.edu Wed Dec 19 17:46:46 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Wed, 19 Dec 2018 22:46:46 +0000 Subject: [python-win32] Initial setup and COM debugging issues. In-Reply-To: <942d3e22-b662-930b-79c5-ae8625b226d3@mclaveau.com> References: , <942d3e22-b662-930b-79c5-ae8625b226d3@mclaveau.com> Message-ID: I did check add to path. I tried different installations on another system, also Win 7 with Visual Studio 2017 installed (including python). In short ActiveState's 32 bit Python didn't work, but using the pywin32 installer did. 1. ActiveState 32 bit version. It does not update the menus, though it does update the path. Many of the programs won't run. C:\Python36\Lib\site-packages\pythonwin\Pythonwin.exe will not; it says it needs mfc100u.dll. The file is in Windows\SysWOW64; despite the name, this is for 32 bit programs running on 64 bit windows. It does not appear in System32, which is for 64 bit dlls! Pythonwin.exe is actually 64 bit according to a tool I wrote. The package doesn't seem to have been built quite right; I uninstall the package. In fairness the fact that there are at least 2 other pythons installed (both 64 bit and both more recent than the ActiveState I installed) probably makes this a challenging environment. 2. Install Python 3.7 32 bit from python.org and download the pywin32 installer and run. This differs from my previous approach, which used pip to get pywin32. This seems to work; I get new menu entries and can run Pythonwin. Note the Visual Studio associated pythons were both 3.6. The lesson seems to be to use the pywin installer, not pip, to install pywin. Coda: I still have COM problems on the new system because it encounters the same problem as before when the file being registered by COM is on the network share: the call to list the file never returns. This seems to be a Windows 7 thing not a python thing, since FindNextFile keeps returning the same file repeatedly when called from C++; VBA shows the same problem. The problems does not occur from Win Server 2012 R2. Visual Studio 2017 says it targets Windows 10 and has no other options I know of. I doubt that's the problem since python and pywin32 may not have been built with it and VBA in Access 2010 certainly wasn't built with it. Ross ________________________________________ From: python-win32 on behalf of mc at mclaveau Sent: Wednesday, December 19, 2018 12:32:24 AM To: python-win32 at python.org Subject: Re: [python-win32] Initial setup and COM debugging issues. Hi! During the installation of python, did you check well to add Python in the PATH? This option is at the very bottom of the frame, and not very visible. @-salutations -- [cid:part1.55697E79.A202DABA at mclaveau.com] Le 18/12/2018 ? 20:58, Boylan, Ross a ?crit : pywin32 is installed just for me, but python itself is installed for all users. I have C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\pythonwin\Pythonwin.exe but when I try to run it (double-click or command prompt in that directory) I get The application can not locate win32ui.pyd (or Python) (126 That file is in the same folder as Pythonwin.exe. Searching turned up some suggestions this is a 32 vs 64 bit problem; everything should be 32 bit (though 64 bit OS) but I'm not sure how to check. The system itself definitely has both 32 and 64 bit pythons installed. Ross ________________________________________ From: python-win32 on behalf of Dennis Lee Bieber Sent: Wednesday, December 12, 2018 11:19:46 AM To: python-win32 at python.org Subject: Re: [python-win32] Initial setup and COM debugging issues. On Wed, 12 Dec 2018 02:10:36 +0000, "Boylan, Ross" declaimed the following: So I think my installation is missing some pieces. I installed the standard Windows version of Python from python.org and used pip to install pywin32. There are a number of different pythons installed on the system. I've always installed ActiveState builds, which include pywin32/win32py (I think the name has changed over its history). To my knowledge PythonWin IDE is included as part of pywin32. Searching suggested the invoked tool was win32traceutil.py; I tried to launch it, but it failed because it had a Python 2 print statement. TraceCollector.py says it is a win32traceutil like utility, so I tried that: C:\Users\rdboylan\AppData\Roaming\Python\Python37\site-packages\pythonwin\pywin\tools>py TraceCollector.py Traceback (most recent call last): I'm guessing you installed Python for single user, given that path. Did you try running the pythonwin executable. Note that the documentation which you trimmed actually states "... for PythonWin" -- which could imply that it is trying to interface with the (expected) pythonwin IDE process -- something you don't have active. I believe all the tools in .../pywin/tools are meant to be invoked by PythonWin itself. PS C:\Users\Wulfraed> Get-ChildItem -Path c:\ -Recurse -Name -Filter "*pythonwin*" Python27\Lib\site-packages\pythonwin Python27\Lib\site-packages\pythonwin\Pythonwin.exe Python35\Lib\site-packages\pythonwin Python35\Lib\site-packages\pythonwin\Pythonwin.exe {Yes, a bit behind -- ActiveState, after all, has to wait for python.org releases before they can start building and testing for their release -- and 3.6, last I looked, is just the core; 3.5 includes a massive number of third party packages} -- Wulfraed Dennis Lee Bieber AF6VN wlfraed at ix.netcom.com HTTP://wlfraed.home.netcom.com/ _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 -------------- next part -------------- A non-text attachment was scrubbed... Name: CUsersCLAVEAUAppDataRoamingThunderbirdsignaturessign-styloplume.GIF Type: image/gif Size: 9129 bytes Desc: CUsersCLAVEAUAppDataRoamingThunderbirdsignaturessign-styloplume.GIF URL: From Ross.Boylan at ucsf.edu Wed Dec 19 17:49:36 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Wed, 19 Dec 2018 22:49:36 +0000 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: References: , <59a1ccc0-0b5a-603b-c486-271484244754@probo.com>, , Message-ID: The same problem occurs from another Win 7 machine so it is not-machine specific, though it might be Win 7 specific. The C++ test program works fine from Win Server 2012 R2, run against the same share. ________________________________________ From: Boylan, Ross Sent: Tuesday, December 18, 2018 11:50:13 AM To: Tim Roberts; python-win32 at python.org Subject: Re: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) BTW, I installed Visual Studio and wrote a little C++ program that exercised FindNextFile. It failed in exactly the same way (returns same filename forever if on a network drive and search spec has the exact file name), but only when run from the original machine. This is only one of many signs that the machine (not PyWin) is messed up; we're getting a replacement. Thanks for your help. Ross P.S. Does anyone know why the python com code is doing a Dir() when it already has the exact file name? ________________________________________ From: Boylan, Ross Sent: Wednesday, December 5, 2018 5:40:56 PM To: Tim Roberts; python-win32 at python.org Subject: Re: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) Yes, the directory is a net share. On a local hard drive I do not experience this problem. If I ask for *.py I get a list back that includes the file. If I ask for "BSTI*" I get back a list of 1 element, the file. But if I ask for "BSTImport.py" it hangs. My experiments with Dir$() in Visual Basic , reported earlier, strongly suggest the problem is that Windows FindNextFile function simply keeps returning the file name forever. I've reported this to the people running the server, though it certainly could be a problem on my local machine. I code in C, but don't have a development environment handy. Hence the test in VBA. Ross ________________________________________ From: python-win32 on behalf of Tim Roberts Sent: Wednesday, December 5, 2018 2:21:33 PM To: python-win32 at python.org Subject: Re: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) Boylan, Ross wrote: > > Is this some kind of string conversion issue? My installation is borked? > Manual debugging statements show sys.argv[0] is 'BSTImport.py'. > > win32api.FindFiles('BSTImport.py') > in a python 3.7 shell (32 bit) hangs. That's quite bizarre. The code for win32api.FindFiles is straightforward. Is this a special directory, like a net share or something? If you ask for *.py, is BSTImport.py in the list you get back? Do you code in C? You might code up a trivial C app to run a FindFirstFile/FindNextFile loop with the same parameters to see if the same thing happens. Of course, I'm not sure what the next step would be, whether that worked or failed. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 From eryksun at gmail.com Wed Dec 19 18:33:09 2018 From: eryksun at gmail.com (eryk sun) Date: Wed, 19 Dec 2018 17:33:09 -0600 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: References: <59a1ccc0-0b5a-603b-c486-271484244754@probo.com> Message-ID: On 12/18/18, Boylan, Ross wrote: > BTW, I installed Visual Studio and wrote a little C++ program that exercised > FindNextFile. It failed in exactly the same way (returns same filename > forever if on a network drive and search spec has the exact file name), but > only when run from the original machine. The find-file handle returned by FindFirstFile[Ex] and used by FindNextFile is a pointer to a structure that includes the directory handle, a pointer to a 4 KiB file-record buffer (unless the caller requests FIND_FIRST_EX_LARGE_FETCH, which uses a 64 KiB buffer), and a pointer to the current entry's offset in the buffer. The buffer gets filled via the native system call NtQueryDirectoryFile[Ex]. The NextEntryOffset field of each variable-sized entry is used to traverse the buffer. The offset value is 0 in the last record. As the FindNextFile calls traverse the buffer, the current-entry pointer is updated for the next call. At the final entry, the pointer gets reset back to the base address. In this case, the next FindNextFile call will scan in a new batch of file records via NtQueryDirectoryFile[Ex]. This continues until the system call returns STATUS_NO_MORE_FILES (0x80000006), in which case FindNextFile fails with the last error set to ERROR_NO_MORE_FILES (18). This is the normal way a directory scan is completed. Here's my guess about what's going wrong in your case. NtQueryDirectoryFile[Ex] can fail with STATUS_BUFFER_OVERFLOW (0x80000005) if the buffer isn't large enough for a complete entry. In practice this shouldn't occur because the buffers used by FindFirstFile[Ex] and FindNextFile are large enough for at least one complete entry. We might have a filesystem that, on subsequent calls, stores a partial last entry in the buffer and fails with STATUS_BUFFER_OVERFLOW. FindNextFile handles this case by forgetting the partial entry, which it does by setting the NextEntryOffset field to 0 in the previous entry, if any. Then, even if there's only a single entry, it continues past the overflow error to return the current entry. When NtQueryDirectoryFile[Ex] is called again, it should resume at the entry that was partially returned in the previous call. But if it was only a single entry, and the buffer-overflow was due to a bug in the device stack, then we'll scan the same entry again with the same buffer-overflow error, and we're stuck in an infinite loop. Probably this bug is due to a filter driver in the device stack, rather than the filesystem driver. From Ross.Boylan at ucsf.edu Wed Dec 19 19:54:26 2018 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Thu, 20 Dec 2018 00:54:26 +0000 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: References: <59a1ccc0-0b5a-603b-c486-271484244754@probo.com> , Message-ID: Eryk, thank you for that very detailed explanation. The directory is on a network share; is NtQueryDirectoryFile[Ex] still the call that would be made for it? Ross ________________________________________ From: eryk sun Sent: Wednesday, December 19, 2018 3:33:09 PM To: python-win32 at python.org Cc: Boylan, Ross Subject: Re: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) On 12/18/18, Boylan, Ross wrote: > BTW, I installed Visual Studio and wrote a little C++ program that exercised > FindNextFile. It failed in exactly the same way (returns same filename > forever if on a network drive and search spec has the exact file name), but > only when run from the original machine. The find-file handle returned by FindFirstFile[Ex] and used by FindNextFile is a pointer to a structure that includes the directory handle, a pointer to a 4 KiB file-record buffer (unless the caller requests FIND_FIRST_EX_LARGE_FETCH, which uses a 64 KiB buffer), and a pointer to the current entry's offset in the buffer. The buffer gets filled via the native system call NtQueryDirectoryFile[Ex]. The NextEntryOffset field of each variable-sized entry is used to traverse the buffer. The offset value is 0 in the last record. As the FindNextFile calls traverse the buffer, the current-entry pointer is updated for the next call. At the final entry, the pointer gets reset back to the base address. In this case, the next FindNextFile call will scan in a new batch of file records via NtQueryDirectoryFile[Ex]. This continues until the system call returns STATUS_NO_MORE_FILES (0x80000006), in which case FindNextFile fails with the last error set to ERROR_NO_MORE_FILES (18). This is the normal way a directory scan is completed. Here's my guess about what's going wrong in your case. NtQueryDirectoryFile[Ex] can fail with STATUS_BUFFER_OVERFLOW (0x80000005) if the buffer isn't large enough for a complete entry. In practice this shouldn't occur because the buffers used by FindFirstFile[Ex] and FindNextFile are large enough for at least one complete entry. We might have a filesystem that, on subsequent calls, stores a partial last entry in the buffer and fails with STATUS_BUFFER_OVERFLOW. FindNextFile handles this case by forgetting the partial entry, which it does by setting the NextEntryOffset field to 0 in the previous entry, if any. Then, even if there's only a single entry, it continues past the overflow error to return the current entry. When NtQueryDirectoryFile[Ex] is called again, it should resume at the entry that was partially returned in the previous call. But if it was only a single entry, and the buffer-overflow was due to a bug in the device stack, then we'll scan the same entry again with the same buffer-overflow error, and we're stuck in an infinite loop. Probably this bug is due to a filter driver in the device stack, rather than the filesystem driver. From eryksun at gmail.com Wed Dec 19 23:00:21 2018 From: eryksun at gmail.com (eryk sun) Date: Wed, 19 Dec 2018 22:00:21 -0600 Subject: [python-win32] win32api.FindFiles hangs (was COM registration hangs up: 32 bit Python 3.7 on 64 bit Win 7) In-Reply-To: References: <59a1ccc0-0b5a-603b-c486-271484244754@probo.com> Message-ID: On 12/19/18, Boylan, Ross wrote: > Eryk, thank you for that very detailed explanation. The directory is on a > network share; is NtQueryDirectoryFile[Ex] still the call that would be made > for it? It's the only system call to scan a directory. It's implemented in the I/O manager by sending an IRP_MJ_DIRECTORY_CONTROL: IRP_MN_QUERY_DIRECTORY request to the device stack. In this case the requested directory information is FileBothDirectoryInformation. Locally, the filesystem for a network share is the MUP device (multiple UNC provider), which proxies access to a redirector such as SMB (mrxsmb). Since the same call works from other systems, it's probably safe to assume the problem is in the local device stack and not the server on the other end of the wire.