Author rubenlm
Recipients r.david.murray, rubenlm, tarek
Date 2010-04-29.12:12:28
SpamBayes Score 6.68879e-05
Marked as misclassified No
Message-id <1272543150.8.0.823219084606.issue8523@psf.upfronthosting.co.za>
In-reply-to
Content
Do you really need the global status? I wrote an onerror that seems to works fine after I modified rmtree with the "return" suggested by r.david.murray. It assumes that: 

if os.listdir fails: the user doesn't have read permissions in the dir;
if os.remove or os.rmdir fails: the user doesn't have write permissions in the dir that contains the file/dir being removed.

There are other reasons it can fail (attributes, acl, readonly filesystem, ...) but having access to the global status doesn't seem to be of much help anyway.

I don't like your fix 2/ because it can fail to copy files if you don't have read permissions for the file but have write permissions in the directory (so you can delete the file). Besides, the behaviour doesn't seem useful.

/1 seems ok to me but to make use of the global status it provides the user must write a somewhat complex recovery code.

All in all it seems the current behaviour of having an onerror function is more user friendly.
History
Date User Action Args
2010-04-29 12:12:30rubenlmsetrecipients: + rubenlm, tarek, r.david.murray
2010-04-29 12:12:30rubenlmsetmessageid: <1272543150.8.0.823219084606.issue8523@psf.upfronthosting.co.za>
2010-04-29 12:12:29rubenlmlinkissue8523 messages
2010-04-29 12:12:28rubenlmcreate