On Wed, 14 Feb 2007, Malcolm Rowe wrote:
> On Thu, Feb 08, 2007 at 09:12:38AM -0800, Daniel Rall wrote:
> > > > More importantly, though, I'm not sure that the API change to
> > > > svn_io_remove_dir() is appropriate. Is there any reason that the single
> > > > caller who wishes to ignore ENOENT can't simply ignore that error?
> > >
> > > The difference is that the new function let's make sure that the directory
> > > actually doesn't exist afterwards. In general, we could have an ENOENT
> > > further down in the tree and in that case, ignoring the error would leave
> > > a half-removed directory. I think this behaviour can be more generally useful
> > > in cleanup actions, hence the new API.
> >
> > I noted the same thing while reviewing this patch; the new API is more generally
> > useful, so worth the change.
>
> Unless I misunderstand what you're suggesting, we could have created
> a specific error to distinguish an ENOENT at the root of the deletion
> (which indicates a 'normal' condition, merely that the directory doesn't
> exist) from an ENOENT midway through the deletion (which indicates
> an unexpected problem), which is something we could have done without
> revving the interface.
You don't misunderstand me, and are spot on.
> But if we think that the API is generally useful, let's keep it (I'm
> not convinced myself, though :-)).
I do find the new API useful along the lines of 'rm' vs. 'rm -f'.
It's a rather common situation in programming that the target of a
deletion may not exist; having a shorthand to handle this situation is
certainly not required, but is a nice convenience. *shrug*
- Dan
- application/pgp-signature attachment: stored
Received on Wed Feb 14 18:55:37 2007