Misleading error message when opening a file (on Windows XP SP 2)

[Claudio Grondi]

Fredrik Lundh wrote:
> Tim Peters wrote:
> 
> 
>>>Traceback (most recent call last):
>>>   File "<pyshell#1>", line 1, in -toplevel-
>>>     f = file('veryBigFile.dat','r+')
>>>IOError: [Errno 2] No such file or directory: 'veryBigFile.dat'
>>>
>>>Is it a BUG or a FEATURE?
>>
>>Assuming the file exists and isn't read-only, I bet it's a Windows
>>bug, and that if you open in binary mode ("r+b") instead I bet it goes
>>away (this wouldn't be the first large-file text-mode Windows bug).
> 
> 
> however, if you use the C level API, you get EINVAL (which presumably means
> that the CRT cannot open this file in text mode), not ENOENT.   this is also true
> for older versions of Python:
> 
> Python 2.1.1 (#20, Aug 23 2001, 11:27:17) [MSC 32 bit (Intel)] on win32
> 
>>>>f = open("bigfile.dat")
>>>>f = open("bigfile.dat", "r+")
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> IOError: [Errno 22] Invalid argument: 'bigfile.dat'
> 
> which probably means that this fix
> 
>     http://www.python.org/sf/538827
> 
> is partially responsible for the misleading error message.
> 
> (the cause of this seems to be that when you open a text file for updating, the
> CRT check if there's a chr(26) at the end of the file, but the 32-bit lseek API
> doesn't support seeking to positions larger than 2^31-2)
> 
> </F> 

Using MSVC++ .NET 2003 compiler (if I did it all the right way):

fstm = fopen("bigfile.dat","r+");
if(fstm == 0) { printf( "  ErrNo: %i \n", errno ); }
//              ^-- prints :
// on "r+" with too large file: 22  (EINVAL-Invalid argument)
// on non-existing file       :  2  (ENOENT-no such file)
// on bad mode string spec.   :  0  (??? why not EINVAL ...)

So there _is_ a way to distinguish the different problems occurred while 
opening the file. The error message comes from Python (errnomodule.c), 
not from Windows(errno.h). Concluding from this it becomes evident for 
me, that this misleading error message is Python fault (even if 
originated by misleading errno values set after fopen in the MSVC++ 
environment and Windows), right?
Probably also in Python 2.5?

Claudio Grondi