It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\\\homeserver\\foo\\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\\foo\\bar\\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\\foo\\bar\\test.txt'

Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

Logged In: YES 
user_id=11105

Tim: I didn't know that.  Thanks for disabling it.

Mark: Sorry, it wasn't your fault.

Logged In: YES 
user_id=565165

This may not be a bug afterall.  I think it has to do with 
Window's ACLs.  I believe os.access is just looking at access 
bits.  For example, I can create a directory and leave it as 
writable, but prevent access to it via an ACL.  In this case, 
os.access reports true, but any operation you try to perform 
on the dictionary get's a permission error.  It might just need 
to be mentioned in the os.access doc.

Thomas: no problem

Logged In: YES 
user_id=31435

Heh -- I didn't know it either, Thomas.  But I've also noticed 
how many new Windows bugs get assigned to you, and got 
curious enough to dig into it.

Logged In: YES 
user_id=555

The submitter seems to want os.access to agree with the
subsequent behavior of I/O operation, but this is not
possible for all cases.  The NFS spec, for example, allows
NFS servers to deny operations in a capricious manner, over
and above any denial that might be due to permissions bits
and/or a volume "read only" flag.  I don't know if there is
an SMB/CIFS server spec, but one could imagine the same
thing happening there.

It might be possible to add ACL checking to the Windows
version of os.access, if a Windows person thinks it's
worthwhile.  It probably would be valuable to add a
clarification to the os.access doc.  For example:

Note that I/O operations may fail even when the access
function indicates that they would succeed, particularly for
operations on network filesystems, which may have
permissions semantics beyond the usual POSIX permission-bit
model.

(Also, if someone does this, please update the doc to note
that access returns True and False, not 1 and 0.)

Logged In: YES 
user_id=33168

Mark or mkc, can you suggest wording to improve the docs? 
Thanks.

Logged In: YES 
user_id=555

nnorwitz: The penultimate paragraph of my comment (the one
that begins "Note that...") is what I'd suggest adding to
the doc...

Logged In: YES 
user_id=33168

Done.  It only took a year plus :-(.

Thanks for the note.

Checked in as:
 * Doc/lib/libos.tex 1.168, 1.146.2.11