Re: [boost] boost/filesystem/directory.hpp attached for comment

From: Ross Smith (r-smith_at_[hidden])
Date: 2002-03-21 05:42:06

-- Dividing everything into "is_directory()" vs "is_file()" doesn't work
on Unix, where there are any number of other things a file system object
might be (devices, pipes, etc.).

-- is_read_only() is nontrivial on Unix, where it would require
complicated checking on user identity, group membership, etc. If the
comment "doesn't imply writable; permissions or the like may make a
non-read-only file still not writable" was intended to cover this, and
to imply that only one (which one?) of the permission bits is checked,
then I can't see the point of having the function at all.

-- There are several versions of "remove" covering various combinations
of file vs directory, remove recursively vs throw if not empty, remove
if exists vs throw if not, but I can't see one for "remove this object,
regardless of whether it's a file or directory; if it's a directory,
remove recursively; if it doesn't exist, silently do nothing" (i.e. the
equivalent of rm -rf), which strikes me as by far the most common
desired semantics.

-- In general, I think you've leaned too far in the "throw on anything
at all out of the ordinary" direction without providing corrseponding
"go ahead and do it anyway" options. E.g. copy_file() and rename() offer
no overwrite option.

-- Incidentally, regardless of the rename() vs move() question (on which
I have no particular preference), isn't there a slight inconsistency
there? I think it should be copy() and rename()|move(), or copy_file()
and rename_file()|move_file(), for consistency.

-- I can't figure out exactly what initial_directory() is supposed to
do. It clearly has something to do with getcwd() and with providing some
kind of substitute on systems that don't support getcwd() or the
equivalent directory, but the detailed semantics aren't clear to me from
the description. (I can't even parse the sentence "Otherwise, if
possible, compile or link." Typo there?)

-- What's the difference between is_file() and existing_file() (and
ditto for ..._directory())?

-- I'm not sure what prune() does. Putting together clues from the
surrounding material, I'm guessing that it removes the contents of a
directory but not the directory itself. That seems a very arcane and
unusual operation to me; is it really common enough to be worthy of a
function in its own right?

-- "Rationale for not providing name, regex, or predicate filtered
versions of remove() or remove_all(): The implication of filtering is
that the starting directory may not be empty on completion of
operations. Thus trying to remove it makes no sense." I'm sorry, I just
can't understand what you're driving at here. Why would it be
undesirable to be able to easily remove only files that match a
condition? I would have thought it would be not only desirable but very
common.

-- Related to some of the above, I see a general pattern of providing
non-recursive and (sometimes) recursive versions of operations, and
treating the non-recursive case as the normal case and the recursive one
as a less prominent variation (when it's provided at all). I would have
thought it would be the other way around -- usually, the recursive case
is the one I want nearly all the time, and the non-recursive case is the
weird special case that's hardly ever useful and often not worth
bothering to provide a single function for.

-- 
Ross Smith ...................................... Auckland, New Zealand
r-smith_at_[hidden] ....................................................
  "We need a new cosmology. New gods. New sacraments. Another drink."
                                                       -- Patti Smith