os.access() under windows

Tim Golden mail at timgolden.me.uk
Tue Dec 4 05:52:38 EST 2007


Martin v. Löwis wrote:
> It would be possible to fix this specific case, by always
> returning True for directories; and perhaps I'll do that for
> 2.5.2.

Martin. Could you confirm that the outline below correctly
describes the behaviour of the os.access function under
Windows, please? If you confirm its accuracy, I'll write it
up as a docs patch against the development docs.

"""
The os.access function originates on Unix where it straightforwardly
reflects the permission-bit model of security. On Windows, that
model does not obtain so the Python function compromises as follows:

+ If the path does not exist or if access if forbidden, return False
+ Requests for access mode R_OK and X_OK will always return True
if the path can be accessed at all.
+ If the path refers to a directory, return True since the readonly
attribute on a directory does not prevent writing files.
+ If W_OK access is requested and the file's readonly flag is set,
return False.
+ If W_OK access is requested and the file's readonly flag is not
set, return True.

NB None of the checks explicitly take into account security
ACLs.
"""

> A more general issue is whether the ACL should also be
> taken into account. This would involve calling things like
> OpenThreadToken, MapGenericMask, and AccessCheck. These are
> all functions from the NT security API, and unavailable
> on Win9x - which is the likely reason why the MS CRT did
> not use them, either. Providing a proper access() implementation
> for NT+ then only becomes possible for 2.6 (where W9x
> is no longer supported).

Agreed. I think I'd like to see that happen, but I have to
down several strengthening drinks every time I approach the
Windows Security API!

TJG



More information about the Python-list mailing list