There's a thread on python-list at the moment: http://mail.python.org/pipermail/python-list/2011-May/1272505.html which is discussing the validity of os.access results on Windows. Now we've been here before: I raised issue2528 for a previous enquiry some years ago and proffered a patch which uses the AccessCheck API to perform the equivalent check, but didn't follow through. Someone on the new thread is suggesting -- validly -- that the docs should highlight the limitations of this call on Windows. But the docs for that call are already fairly involved: http://docs.python.org/library/os.html#os.access We seem to have a few options in increasing order of difficulty: * Do nothing - inform the occasional enquirer of the situation and leave it at that. * Update the docs to add something which describes what the function actually does on the Windows platform. (Whether or not we change any code). * Apply the patch in issue2528 to 3.3 and maybe 2.7 * Leave os.access alone but offer alternative Windows-specific functionality in the os module or elsewhere, using essentially the code in the issue2528 patch. As a side note, the pywin32 packages don't actually include AccessCheck at the moment. (Which makes it slightly harder to explain to people how they could do this check for themselves). It could probably be added over there which might ease the burden over here. Opinions? TJG Tim Golden Very Senior Analyst Programmer CBS Outdoor UK Camden Wharf 28 Jamestown Road London NW1 7BY T: 020 7482 3000 F: 020 7267 4944 http://www.cbsoutdoor.co.uk/ http://www.cbsoutdoor.co.uk/ http://www.bigbuschallenge.com/ Don't waste paper. Think before you print. The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed, and may also be privileged. If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this e-mail in error, please e-mail the sender by replying to this message. CBS Outdoor Ltd reserves the right to monitor e-mail communications from external/internal sources for the purposes of ensuring correct and appropriate use of CBS Outdoor facilities. CBS Outdoor Limited, registered in England and Wales with company number 02866133 and registered address at Camden Wharf, 28 Jamestown Road, London, NW1 7BY. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
On Fri, May 20, 2011 at 03:38, Tim Golden
There's a thread on python-list at the moment:
http://mail.python.org/pipermail/python-list/2011-May/1272505.html
which is discussing the validity of os.access results on Windows. Now we've been here before: I raised issue2528 for a previous enquiry some years ago and proffered a patch which uses the AccessCheck API to perform the equivalent check, but didn't follow through.
Someone on the new thread is suggesting -- validly -- that the docs should highlight the limitations of this call on Windows. But the docs for that call are already fairly involved:
http://docs.python.org/library/os.html#os.access
We seem to have a few options in increasing order of difficulty:
* Do nothing - inform the occasional enquirer of the situation and leave it at that.
* Update the docs to add something which describes what the function actually does on the Windows platform. (Whether or not we change any code).
I think we should tread lightly in the documentation area. We already have two note boxes, and adding a third probably scares everyone away. Maybe there should be a bullet list of considerations to be made when using os.access? * Apply the patch in issue2528 to 3.3 and maybe 2.7
I'd vote in favor of this. If we can be a bit smarter in determining os.access results, let's do it. I haven't reviewed the patch other than 1 minute scan, but I'll put this on my radar and try to get you a review.
On 20/05/2011 16:21, Brian Curtin wrote:
On Fri, May 20, 2011 at 03:38, Tim Golden
I think we should tread lightly in the documentation area. We already have two note boxes, and adding a third probably scares everyone away.
I entirely agree. (That's what I meant by "involved" above)
Maybe there should be a bullet list of considerations to be made when using os.access?
* Apply the patch in issue2528 to 3.3 and maybe 2.7
I'd vote in favor of this. If we can be a bit smarter in determining os.access results, let's do it.
I haven't reviewed the patch other than 1 minute scan, but I'll put this on my radar and try to get you a review.
Thanks. To be honest I wrote the patch 3 years ago; I haven't even tried to apply it to either of the current posixmodule.c. Let's see if I can dust it off and mould it into shape, or you'll be left fighting patch errors instead of reviewing code :) TJG
On May 20, 2011 8:30 AM, "Tim Golden"
On 20/05/2011 16:21, Brian Curtin wrote:
On Fri, May 20, 2011 at 03:38, Tim Golden
I think we should tread lightly in the documentation area. We already have two note boxes, and adding a third probably scares everyone away.
I entirely agree. (That's what I meant by "involved" above)
TBH I think the less attractive we can make os.access() look the better. It uses the real uid instead of the effective uid, it encourages LBYL behavior, the outcome may be incorrect, it doesn't work on Windows... The ONLY reason to ever use it is in a setuid() program. But who writes those any more? (Esp. in Python!) -- --Guido van Rossum (python.org/~guido)
TBH I think the less attractive we can make os.access() look the better. It uses the real uid instead of the effective uid, it encourages LBYL behavior, the outcome may be incorrect, it doesn't work on Windows... The ONLY reason to ever use it is in a setuid() program. But who writes those any more? (Esp. in Python!)
+1. The best way to determine "could I access this file" is to try to access it, and be prepared to get an exception. So we might deprecate-then-delete it on Windows. People who *really* need to know in advance should use the Windows API for that on Windows (i.e. call AccessCheck). Regards, Martin
On 20/05/2011 22:56, "Martin v. Löwis" wrote:
TBH I think the less attractive we can make os.access() look the better. It uses the real uid instead of the effective uid, it encourages LBYL behavior, the outcome may be incorrect, it doesn't work on Windows... The ONLY reason to ever use it is in a setuid() program. But who writes those any more? (Esp. in Python!)
+1. The best way to determine "could I access this file" is to try to access it, and be prepared to get an exception.
FWIW the OP knew this but -- for some reason specific to his use case -- wanted to avoid updating the mod dates of the containing directory. Obviously that's his problem, not ours...
So we might deprecate-then-delete it on Windows.
I'll rework that patch to be a DeprecationWarning in that case.
People who *really* need to know in advance should use the Windows API for that on Windows (i.e. call AccessCheck).
And indeed this is what I've recommended to the OP. I'll follow this up in that python-list thread. I see that Benjamin's updated the os.access docs so I'll let this thread die and talk the OP through the AccessCheck route (which is, unfortunately, more tricky because it's not exposed by pywin32. Also not our problem...) TJG
participants (5)
-
"Martin v. Löwis"
-
Brian Curtin
-
Guido van Rossum
-
Tim Golden
-
Tim Golden