> * R_OK: A process with bypass-traversal-check priv. enabled
> doesn't need any access to intervening directories in order
> to get the attributes of a file within them. This means that
> our existing R_OK result is accurate for any file: if we can
> get its attributes then you can open the file f
[apologies if this double-posts; my email server's playing up]
Martin v. Löwis wrote:
> In a POSIX world, you need read permission on the directory.
> In Windows, with the "bypass-traversal-check" privilege,
> you only need read permission on the directory if you want
> to list it, not to acce
Martin v. Löwis wrote:
> In a POSIX world, you need read permission on the directory.
> In Windows, with the "bypass-traversal-check" privilege,
> you only need read permission on the directory if you want
> to list it, not to access a file in the directory. Is it
> actually possible for GetFileAtt
> Up to a point: this meets the case where we fail to access
> the file at all (for read or write or whatever). But what
> about where we can read the directory entry, and the
> read-only attribute isn't set? At present, we'll return
> True to a W_OK access check in these circs, but this user
> mig
Martin v. Löwis wrote:
>> Now, ironically, I'm confused by your recap :) What I meant to say was
>> that the os.access function as implemented under Windows returns False
>> if the path in question (say, "x:\someones-private-docs\diary.doc") was
>> inaccessible to the process invoking os.access by
> Now, ironically, I'm confused by your recap :) What I meant to say was
> that the os.access function as implemented under Windows returns False
> if the path in question (say, "x:\someones-private-docs\diary.doc") was
> inaccessible to the process invoking os.access by virtue of file
> system per
Martin v. Löwis wrote:
>> Martin. Could you confirm that the outline below correctly
>> describes the behaviour of the os.access function under
>> Windows, please?
>
> It's correct for Python 2.5.2 and 2.6; for 2.5.1 (as discussed)
> the test "if directory:return True" was not implemented.
Thanks
> Martin. Could you confirm that the outline below correctly
> describes the behaviour of the os.access function under
> Windows, please?
It's correct for Python 2.5.2 and 2.6; for 2.5.1 (as discussed)
the test "if directory:return True" was not implemented.
Notice that the first sentence:
"If t
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 conf
Martin v. Löwis wrote:
> 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
> 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
Yann Leboulanger wrote:
> Ok thanks for all those information, I'll remove the call to os.access()
> on folders for windows in my application.
>
FWIW, I think it's worth bearing in mind what was said
earlier in this thread: it's easier to ask forgiveness
than permission. Technically, even if os.
Tim Golden a écrit :
> Well, that's not the case for files: if you set your
> file's readonly attribute to True, then os.access (W_OK)
> will return False and you won't be able to write to the
> file:
> The only issue (at least, the only one we're discussing here) is:
> If os.W_OK on a directory
Yann Leboulanger wrote:
> Tim Golden a écrit :
>>
>> I'm happy to contribute a doc patch if I can imagine what
>> exactly to write.
>>
>
> "Don't use it under windows, always consider it's True"?
Well, that's not the case for files: if you set your
file's readonly attribute to True, then os.acces
Tim Golden a écrit :
>
> I'm happy to contribute a doc patch if I can imagine what
> exactly to write.
>
"Don't use it under windows, always consider it's True"?
Maybe it would be a good idea to remove support for windows for this
function, or make it always return True?
Current behaviour is w
Tim Golden wrote:
> Yann Leboulanger wrote:
>> Martin v. Löwis a écrit :
I create a folder test under e:
then os.access('e:\\test', os.W_OK) returns True. Everything's ok.
Now I move My Documents to this e:\test folder
Then os.access('e:\\test', os.W_OK) returns F
Yann Leboulanger wrote:
> Martin v. Löwis a écrit :
>>> I create a folder test under e:
>>>
>>> then os.access('e:\\test', os.W_OK) returns True. Everything's ok.
>>>
>>> Now I move My Documents to this e:\test folder
>>>
>>> Then os.access('e:\\test', os.W_OK) returns False !!
>> This description
Martin v. Löwis a écrit :
>> I create a folder test under e:
>>
>> then os.access('e:\\test', os.W_OK) returns True. Everything's ok.
>>
>> Now I move My Documents to this e:\test folder
>>
>> Then os.access('e:\\test', os.W_OK) returns False !!
>
> This description is, unfortunately, too imprecis
> I create a folder test under e:
>
> then os.access('e:\\test', os.W_OK) returns True. Everything's ok.
>
> Now I move My Documents to this e:\test folder
>
> Then os.access('e:\\test', os.W_OK) returns False !!
This description is, unfortunately, too imprecise to allow reproducing
that effect
David Tweet wrote:
> To answer indirectly, usually the EAFP (easier to ask forgiveness than
> permission) approach works better for this kind of thing.
>
> try:
> f = open('e:\\test\\test', 'a')
> f.write('abc')
> f.close()
> except IOError:
> print "couldn't write test file, continuing...
To answer indirectly, usually the EAFP (easier to ask forgiveness than
permission) approach works better for this kind of thing.
try:
f = open('e:\\test\\test', 'a')
f.write('abc')
f.close()
except IOError:
print "couldn't write test file, continuing..."
On Dec 1, 2007 1:48 AM, Yann Lebou
21 matches
Mail list logo
