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 -- http://mail.python.org/mailman/listinfo/python-list
