Newby help

David Bolen db3l at fitlinxx.com
Thu May 4 00:22:25 CEST 2000


"Dale Strickland-Clark" <dale at out-think.NOSPAMco.uk> writes:

> Sussed it (I knew this would happen. Stare at it for hours then as soon as
> you post the question, the answer hits you!)
> 
> The initial directory doesn't exist. The first call to 'walk' should have
> been: walk("D:\\....").
> 
> Top prize for a crap error message, though!
> 
> If it had mentioned 'file' or 'directory', I might have found it sooner.

The problem in this case appears to be Python letting a Windows return
code bubble up and then get treated as a Unix/cygwin errno value.
When the internal posix module in Python does the initial search for a
file entry in the supplied path, it gets back an error code of 3,
which under Windows is ERROR_PATH_NOT_FOUND.  However, that bubbles up
into an errno translation which translates to ESRCH (No such process).

In many cases this works fine since the error is being generated by a
module using Unix-like semantics through Cygwin, but in this case it's
coming straight from a Win32 FindFirstFile() call without translation.

So you're getting the proper error code being reported, it's just
being inaccurately translated to a string.  Trying to build a
translation system between the Windows error codes and errno values is
probably more hassle than it's worth, but I agree that presenting the
errno string translation in this case is misleading.

One option at times like this is to use the win32api module from the
Win32 extensions package to format the actual Windows error:

   >>> import win32api
   >>> print win32api.FormatMessage(3)
   The system cannot find the path specified.

at least when trying to diagnose items - or if you know you're in the
win32 environment, as part of your own exception handler.  This will
work for all of the base errors, although it gets more complicated for
module specific (e.g., RAS) errors since you have to load the DLL
containing the error messages.  Of course, at that point you're
already pretty Win32 specific for using those modules in the first place.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list