apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] apr_dir_remove_recursively
Date Wed, 23 May 2001 16:45:38 GMT
From: "Ben Collins-Sussman" <sussman@collab.net>
Sent: Wednesday, May 23, 2001 11:35 AM


> "William A. Rowe, Jr." <wrowe@rowe-clan.net> writes:
> 
> > > What if 3 different files in the tree (scattered about) are
> > > un-removable for different reasons?  This function still removes
> > > everything else and finishes its recursion.  Which of the three status
> > > codes should it return?
> > 
> > The first it encountered.
> > 
> > Here's the scenario...
> > 
> > path/to/some/where/file
> > 
> > If we remove 'some', and fail at file due to EACCESS, we will fail
> > at 'where' as well since it contains files, and at 'some' since it
> > contains a directory.  We don't care that we failed because files
> > remain, we care why that file remains in the first place.
> 
> Sorry, I'm still not following you.  Your explanation makes me think
> that as *soon* as any object returns a remove-error, all recursion
> should immediately return.  
> 
> This contradicts the earlier goal of "delete everything it can anyway"
> -- which implies finishing the whole depth-first search and just
> caching any remove-errors along the way.
> 
> So which design do we want?  Return-on-first-error, or
> Return-with-a-list-of-errors?

Stow the first error encountered, continue to attempt to remove everything
we can, then return that first error.


Mime
View raw message