Python open w/ MSVC6: bad error msgs

[glchapman]

BPO	538827
Nosy	@mwhudson, @tim-one, @mhammond
Files	fileobject.patch: MSVC errno-fiddling patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tim-one'
closed_at = <Date 2002-04-08.04:20:05.000>
created_at = <Date 2002-04-03.17:10:52.000>
labels = ['OS-windows']
title = 'Python open w/ MSVC6: bad error msgs'
updated_at = <Date 2002-04-08.04:20:05.000>
user = 'https://bugs.python.org/glchapman'

bugs.python.org fields:

activity = <Date 2002-04-08.04:20:05.000>
actor = 'tim.peters'
assignee = 'tim.peters'
closed = True
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2002-04-03.17:10:52.000>
creator = 'glchapman'
dependencies = []
files = ['411']
hgrepos = []
issue_num = 538827
keywords = []
message_count = 7.0
messages = ['10134', '10135', '10136', '10137', '10138', '10139', '10140']
nosy_count = 4.0
nosy_names = ['mwh', 'tim.peters', 'mhammond', 'glchapman']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue538827'
versions = ['Python 2.2']

[glchapman]

With the current Win32 build (actually, 2.2.1c1), you
get the following behavior when feeding bad filenames
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error
ERROR_INVALID_NAME to EINVAL, and Python always treats
this error as being related to the mode string. It
appears (from bug report 476593) that VC6 disagrees
with GCC here; I don't know which compiler is right
(actually, looking at the VC documentation for _open,
it appears GCC is right). At any rate, it appears
Python cannot rely on EINVAL referring only to the
mode string under Windows.

Interestingly, the current Python Win32 build also
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen
fails, but it does not set errno. (You can see this
in the openfile function in _OPEN.C in the VC6 CRT
source). It might be possible to use this behavior to
produce more accurate error messages under Windows.

[mwhudson]

Logged In: YES
user_id=6656

Guess who gets to look at this one.

[tim-one]

Logged In: YES
user_id=31435

Which version of Windows are you using? Here on Win98SE, I
get

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'
>>>

all the way back through Python 2.0. Note that MS's error
translation table (in DOSMAP.C) doesn't contain an entry
for ERROR_INVALID_NAME, so the logic in _dosmaperr() would
return EINVAL in that case (it can't dream up anything
better to return). The errors CreateFile *can* trigger
aren't documented, and I expect they vary across Windows
flavors (and that Win98SE triggers ERROR_FILE_NOT_FOUND in
this case, which maps to ENOENT).

Note that MS doesn't catch all senseless mode strings
either. For example,

>>> open('wtf', 'w hi greg!')
<open file 'wtf', mode 'w hi greg!' at 0x00768F30>
>>>

If you want to create a patch to clean up MS's mess here,
be my guest.

[glchapman]

Logged In: YES
user_id=86307

I'm using Windows 2000; I also just tested this on Windows
XP Pro and got the same results (as on Windows 2000).

As far as a patch, the simplest thing might be to add an
ifdef so that EINVAL is not treated as a special case when
compiling with VC; this would revert to the behavior before
November 2001 (i.e., the patch for bug 476593). If this
path is chosen, should there be a special define introduced
for invalid use of EINVAL (I don't know if other C
libraries have this problem), or should it simply refer to
MSVC?

The above wouldn't fix the problem with MS's handling of
invalid mode strings. I had noticed that you could put
anything in a mode string provided the first character was
in [rwa]. How do other C libraries handle these kind of
errors in mode strings? I have the source to Borland C++
Builder 4. It looks like it checks the entire mode string,
but it also fails without setting errno if it finds any
invalid characters. Is fopen expected to set errno on
failure? (I note that neither the MS nor the Borland
documentation for fopen refers to errno.)

[tim-one]

Logged In: YES
user_id=31435

I'm afraid there are no answers to your questions short of
doing an exhaustive study of each implementation of
interest, and even then it hits a brick wall because Win32
CreateFile() doesn't document its error conditions and its
source code is secret.

I'm attaching a patch that should reliably distinguish
between mode and filename errors across Windows flavors
under MSVC, and that maps EINVALID to ENOENT on Windows
(which may not be the best that *could* be done on Win2K,
but Windows flavors are inconsistent here and Python has no
idea which flavor of Win32 it's running under). If that's
good enough for you, I'll check it in,; else I'm inclined
to close this as 3rdParty and Won'tFix.

[mhammond]

Logged In: YES
user_id=14198

Confirming that on Win2k, before the patch I see:
>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

and after:
>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'

and a quick scan shows the patch to be reasonable. So +1 on
checking it in.

[tim-one]

Logged In: YES
user_id=31435

Based on Mark's confirmation and reviewlet, I'm closing
this report. The patched logic was checked in on the trunk
and on the 2.2.1 branch (so will be in 2.2.1 final later
this week).