[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