(python 2.3b on Windows XP, regular user account)

Problem running test.test_os:

==============================================================
ERROR: test_tmpfile (__main__.TemporaryFileTests)
--------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 49, in test_tmpfile
    fp = os.tmpfile()
OSError: [Errno 13] Permission denied

==============================================================
ERROR: test_tmpnam (__main__.TemporaryFileTests)
--------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 61, in test_tmpnam
    self.check_tempfile(os.tmpnam())
  File "Lib\test\test_os.py", line 29, in check_tempfile
    open(name, "w")
IOError: [Errno 13] Permission denied: '\\sd4.'


It appears Python 2.3b has troubles writing to a file
returned by os.tmpnam(), because when I try this on
Python 2.2:
>>> open(os.tmpnam(),"w")
<open file '\s128.8', mode 'w' at 0x0091BCC8>

Where Python 2.3b gives:
>>> open(os.tmpnam(),"w")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission denied: '\\sg4.1'

Logged In: YES 
user_id=129426

Extra info:
Forget about Python 2.2, I tried again and it doesn't work
with 2.2 either. I found out why: My user account has no
write access in the root of C:\  !!  I don't know about the
format of the filenames returned from os.tmpnam(), but it
appears that they are created in the root of  the current
drive, which fails if that is C:\ -- where I have no write
access.

Needless to say, it works fine when running with
administrative priviliges because then we are allowed to
write in the root of C:\

Logged In: YES 
user_id=699438

There are a couple of issues here.

Windows XP puts some crazy acls on the root of c:  It looks 
like the first phase of shutting off all write access for users to 
the root, with a wierd hack for legacy programs.  Anyone can 
create a file/directory on the root of C:\, but once they do they 
take ownership.  At that point, only SYSTEM, 
ADMINISTRATORS, and the CREATOR OWNER have full 
control, but all users still have read/execute access.

Another problem is listed in the documentation for tmpnam(). 

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vclib/html/_crt__tempnam.2c_._wtempnam.2c_.tmpnam.2c
_._wtmpnam.asp

 If I'm reading it right, it says that if the filename starts with 
a "\", it's really a relative location in the current working 
directory.  But if you just try to pass "\file" as a filename to 
most functions, it'll assume it's the root of the active drive, not 
the working directory.  I don't know if the proper fix would be 
to append a "." to the begining of the filename (".\file"), or to 
return the fully qualified path.

Default root permissions on XP:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>cd \

C:\>xcacls c:\
c:\ BUILTIN\Administrators:(OI)(CI)F
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    CREATOR OWNER:(OI)(CI)(IO)F
    BUILTIN\Users:(OI)(CI)R
    BUILTIN\Users:(CI)(special access:)
                      FILE_APPEND_DATA

    BUILTIN\Users:(CI)(IO)(special access:)
                          FILE_WRITE_DATA

    Everyone:R


C:\>

Logged In: YES 
user_id=31435

This looks hopeless.  I changed the docs to recommend not 
using os.tmpnam() on Windows (it's too bizarre), and 
changed the test to avoid attempting opening the file on 
Windows.