> http://support.microsoft.com/kb/326549 > > Goodness knows what we're supposed to do with that.
Just in case it's not clear what Tim is getting at: if a folder is marked read-only on Windows, it doesn't mean that you can only read from it. The read-only bit is a legacy thing, anyway, since you are supposed to use ACLs to mark a folder as read-only (by only granting write access to those who are supposed to write) As the read-only bit is otherwise unused, Explorer uses it to mark folders as being special, such a My Documents. So by redirecting My Documents, you set the read-only bit on the folder, causing access() to claim that write access is not granted. > Part of the issue here is that we're using a Unix-style > access API against Windows-style filesystem semantics. > According to the man pages, it looks as though it basically > checks the standard security bits against whatever you're > asking for for your user. On Windows, the security semantics > are quite different and you have to make some kind of > decision as to what the os.access means. > > I'm happy to contribute a doc patch if I can imagine what > exactly to write. 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. 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). Regards, Martin P.S. I would never guessed that "move My Documents to test" doesn't mean "drag-and-drop My Documents into test", but "redirect My Documents to the test folder". -- http://mail.python.org/mailman/listinfo/python-list
