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 23:48:20 GMT
From: "Greg Stein" <gstein@lyra.org>
Sent: Wednesday, May 23, 2001 6:25 PM

> On Wed, May 23, 2001 at 05:46:07PM -0500, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <gstein@lyra.org>
> > Sent: Wednesday, May 23, 2001 5:21 PM
> > 
> >...
> > > remove() on a symlink does *not* toss the target. It only removes the
> > > symlink.
> > 
> > BUT... this is a recursive call, he walks to the end of the chain, and starts
> > walking back up the tree.  That means all the files IN the symlinked directory
> > would be cleared out, and the symlink removed, and the original parent directory
> > [now empty] would persist.
> Ah, right. As Greg Marr pointed out, I'm quite wrong in this regard. I
> forgot about the recursion down into directories.
> I would suggest doing the lstat() IFF a directory is found. e.g. don't
> bother with it on files.
> >...
> > > So... don't do an lstat. That is just wasteful and unneeded.
> > 
> > No lstat, we should be able to get that information in the apr_dir_read call.
> I'd say "no" on that. You only want to do the lstat() conditionally.

with a caviat (that we may have to work out the details of...) _if_ the usual
apr_dir_read call indicates (through the valid bits) that the APR_FINFO_TYPE bit 
is toggled provided, there is no reason to call lstat.

But if APR_FINFO_TYPE isn't set, we don't know if it's a directory, either.

Note this little bit of code in apr/file_io/unix/dir.c

    if (wanted)
        /* ??? Or lstat below?  What is it we really want? */
        ret = apr_stat(finfo, fspec, wanted, thedir->cntxt);

Seems we want lstat, doesn't it?  

Which leads to an interesting question, do many platforms offer the d_type member
in the DIR struct?  It appears in FreeBSD 4.2, and would certainly optimize this
scenario significantly for UNIX.  Of course, we need to know that a link is going
to map to DT_LNK, and doesn't return some other file type.  I'd trust that's true.

The obvious question, who knows the spell to identify if DIR d.d_type is valid,
and that (at least) DT_DIR, DT_LNK, DT_REG, etc are defined as well?  Then we
can begin crafting this sucker to perform very efficiently on any platform that
returns the type as part of the readdir call.  By the way, apr_dir_read on win32 
_will_ identify a junction (symlink) as APR_LNK.


View raw message