[MERGE] [BUG 363837] Catch _win32_delete_readonly failure to remove file or directory and try to recover

Alexander Belchenko bialix at ukr.net
Wed May 6 10:01:58 BST 2009


Maritza Mendez пишет:
> 
> 
> On Tue, May 5, 2009 at 8:54 AM, Aaron Bentley <aaron at aaronbentley.com 
> <mailto:aaron at aaronbentley.com>> wrote:
> 
>     -----BEGIN PGP SIGNED MESSAGE-----
>     Hash: SHA1
> 
>     Maritza Mendez wrote:
>      > The more I think about this, the more I think that a cure may be
>     worse
>      > than the problem.  So I am leaning toward...
> 
>      > bzr would catch the exception, print a polite message
>      > about the external misbehavior, and just keep going.
> 
>     I think that this would be fine, so long as it's an opt-in behaviour.
>     If you do it as an onerror callback, note that problems may cascade,
>     because failure to delete a file can cause failure to delete its
>     containing directory.
> 
>     Aaron 
> 
> 
> I think it is "opt-in" enough to limit the response to catching  OSError 
> and ignoring all other exceptions.  What do you think?  At worst, bzr 
> would continue to miss some things it misses now.
> 
> I have to remind myself that this whole discussion comes from the fact 
> that _win32_delete_readonly does not robustly handle failures in 
> osutils.rmtree call to shutil.rmtree.  Since that seems to be the whole 
> purpose of _win32_delete_readonly, I might suggest that osutils.rmtree 
> and _win32_delete_readonly do not meet design requirements.

Which one design requirements?

The _win32_delete_readonly function intended to help in the cases where 
bzr need to remove file marked as read-only. Nothing more. There is 
special test in test_osutils.py to ensure this behavior.

>  That's also 
> why I originally proposed fixing the problem right there, but my fix had 
> problems of its own.  So I think the minimalist path we are on now is good.
> 
> -M
> 




More information about the bazaar mailing list