[Python-Dev] Special file "nul" in Windows and os.stat

[Eric Smith]

Fred Drake wrote:
> On Oct 24, 2007, at 4:23 PM, Facundo Batista wrote:
>> There (and always talking in windows), the OP says the in Py2.4
>> os.path.exists("nul") returned True and now in 2.5 returns False. Note
>> that "nul" is an special file, something like /dev/null.
> 
> It's special, but in a different way.  /dev/null really exists in the  
> Unix filesystem; "nul" is more magical than that.
> 
> What's more, it has peers: "prn", "com1" and others like that.

It's even worse than that, because file extensions are ignored in this 
magical-ness:

C:\Documents and Settings\User>type nul

C:\Documents and Settings\User>type nul.lst

C:\Documents and Settings\User>type foo.lst
The system cannot find the file specified.

> I don't know what the right way to handle these is (I'm no Windows  
> guru, or even regular user), but it's important to realize that the  
> pain of the specialness isn't limited.  :-)

http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part3/proch17.mspx?mfr=true 
gives the list as CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, 
PRN, NUL; but I can't imagine testing against that list would be the 
best idea.  For example, 
http://www.microsoft.com/technet/solutionaccelerators/cits/interopmigration/unix/unixbld/unixbld4.mspx 
adds CLOCK$, among others (although I don't find CLOCK$ to be special, 
it's rumored to be an NT only thing, and I'm running XP).  So I think 
implementing Facundo's option 2 (test for "nul") will not work in the 
general case for finding "special files" (don't forget to throw in mixed 
case names).  I hate to think of trying to match Windows' behavior if 
there are multiple dots in the name.

I think I'd leave the current behavior of calling the kernel function, 
even though it varies based on Windows version (if I'm reading the issue 
correctly).

Eric.