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 I
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 th
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
11:50:13 AM
To: Tim Roberts; python-win32@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
ber 5, 2018 5:40:56 PM
To: Tim Roberts; python-win32@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
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 driv
ython.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.boy...@ucsf.edu:
win32api.FindFiles() works when the
de 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@python.org
Subject: Re: [python-win32] win32api.FindFiles hangs (
on
behalf of ckk...@hoc.net
Sent: Wednesday, December 5, 2018 6:48:21 AM
To: python-win32@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.
Chr
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
str
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.boy...@ucsf.edu:
win32api.FindFiles() works when the argument is "*" or "*.py". It
works, in the sense of returni
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.arg
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.
__
13 matches
Mail list logo
