apr-dev mailing list archives

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


> "William A. Rowe, Jr." <admin@rowe-clan.net> writes:
>  
> > My personal preference is that the remove continues to run, leaving only
> > droppings it can't remove.  Nothing irks me more than fixing the 'one file'
> > that couldn't be removed, only to trip over the next one on the next pass.
> > And save the first failure result for return to the caller.
> 
> I agree.  I'm thinking of rewriting it to leave files behind.  I
> suspect the routine could return either APR_SUCCESS (if nothing but
> was left behind), or some not-yet-invented error code that
> specifically means it wasn't able to remove everything.

should simply return the error that the _remove returned, so if there is
an error, there was some reason it wasn't completed.  But it still completes
all that it is allowed.

> > Does it make sense to apply some lstat check against the tree, such that
> > symlinks' targets aren't blown away?  I'm not clear if your patch protects 
> > that or not.
> 
> Good idea.

Don't go lstating until you've checked the returned flags, the apr dir stuff
can, on some platforms, tell if it's a symlink.  Dunno about all of them.

Bill


Mime
View raw message