apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Collins-Sussman <suss...@collab.net>
Subject Re: [PATCH] apr_dir_remove_recursively
Date Wed, 23 May 2001 16:35:09 GMT
"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

View raw message