Re: [boost] Filesystem: remove_all should not follow symlinks

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2003-11-24 22:09:22

Beman Dawes <bdawes_at_[hidden]> writes:

> Explicit dereferencing would be awfully cumbersome. People using O/S's which
> natively support symbolic links would likely view it as a giant step backward
> for them. Plus there would be interoperability problems - programs using
> Boost.Filesystem wouldn't work the way other programs worked.

I don't like the idea of explicit dereferencing either, but the
alternatives don't seem much better:

One possible alternative is to make functions like is_directory,
is_empty, last_write_time, etc. implicitly dereference symlinks, making
them equivalent to using stat, while providing another set of functions
that operate on the symlink directory (i.e. lstat).  There are a number
of problems with this approach, namely that it is not clear what the
semantics of exists should be (probably it should operate on the symlink
directly, and another function, such as is_valid_symbolic_link, could
indicate if the pointed to file exists), and as additional property
retrieving functions are added to the library, this doubling of
functions becomes more unwieldy.

Instead of using a separate set of functions, a function such as
"protect_link" or "on_link" could be provided that returns a proxy
object, which indicates to the property fetching functions that they
should operate on the symlink directly.

Both of these alternatives seem more convoluted and confusing than
simply requiring explicit dereferencing of symlinks.  A possible
variation on this, that might be more acceptable, would be to implicitly
dereference symlinks when the operation is always meaningless on a link.
Specifically, directory_iterator, and use of a path to open a file could
implicitly dereference symlinks.  Implicit dereferencing could also be
provided for is_directory.  (Although "is_symbolic_link(ph) &&
is_directory(*ph)" makes more sense to me than "is_symbolic_link(ph) &&
is_directory(ph)").  This might be the optimal solution.

>> On an unrelated note, perhaps this has already been discussed, but
>> remove_recursive seems like a better name than remove_all.  Also
>> current_directory and initial_directory seem like better names than
>> current_path and initial_path.

> Those were the original names. But then someone pointed out that these functions
> return full paths, not just a single directory!

Although they return paths, since the boost filesystem library does not
have any way to represent a directory (only a reference to a directory,
namely a path), and is_directory is true for the paths returned, I
think it would be reasonable to use the name directory.

As far as remove_all, my rationale for using the name remove_recursive
instead is that the term "recursive" is often used to characterize such
an operation, while I have not heard of the term "all" being used to
characterize it.  In fact, I would expect a function remove_all to take
a sequence of paths, and remove each of them.

-- 
Jeremy Maitin-Shepard