| msg21619 - (view) |
Author: Mark Moales (mmoales) |
Date: 2004-07-15 17:08 |
| 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 "", line 1, in ? IOError: [Errno 13] Permission denied: 'h:\\foo\\bar\\test.txt' |
|
|
| msg21620 - (view) |
Author: Thomas Heller (theller) *  |
Date: 2004-07-15 18:41 |
| Logged In: YES user_id=11105 Please don't assign windows bugs to me. Thanks. |
|
|
| msg21621 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2004-07-15 18:56 |
| 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). |
|
|
| msg21622 - (view) |
Author: Thomas Heller (theller) * |
Date: 2004-07-15 19:20 |
| Logged In: YES user_id=11105 Tim: I didn't know that. Thanks for disabling it. Mark: Sorry, it wasn't your fault. |
|
|
| msg21623 - (view) |
Author: Mark Moales (mmoales) |
Date: 2004-07-15 19:25 |
| 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 |
|
|
| msg21624 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2004-07-15 20:59 |
| 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. |
|
|
| msg21625 - (view) |
Author: Mike Coleman (mkc) |
Date: 2004-07-29 19:28 |
| 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.) |
|
|
| msg21626 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2004-08-02 22:18 |
| Logged In: YES user_id=33168 Mark or mkc, can you suggest wording to improve the docs? Thanks. |
|
|
| msg21627 - (view) |
Author: Mike Coleman (mkc) |
Date: 2004-08-03 04:39 |
| 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... |
|
|
| msg21628 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2005-10-03 05:14 |
| 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 |
|
|