RE: [boost] filesystem/directory.hpp header redux

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-28 15:00:00

From: Beman Dawes [mailto:bdawes_at_[hidden]]
> 
> At 08:53 AM 3/28/2002, Stewart, Robert wrote:
> 
>  > Thus, I'd expect "prune" -- or
>  >whatever name you may prefer -- to mean that the directory 
> to remove need
>  >not be empty.
> 
> Well, "force" or "trim" are the words that come to mind.  The copy 

Webster says that to prune is "to reduce especially by eliminating
superfluous matter."  That fits eliminating files from directories pretty
well, don't you think?

> operation is going to need an option to indicate that it is 
> OK to overwrite 
> existing target files. "force" would work for that, too.  But 

I should think "overwrite" would be most appropriate, even if it shares the
same value as "prune" or whatever you choose.

> something 
> that had the word "files" in it would be most explicit:
> 
>    remove( "foo", including_files );

That's OK, but a little wordy.

> Well, we still need an option to indicate not to remove a 
> directory that 
> isn't empty.  I like "prune", but "if_empty" might be better:
> 
>    remove( "foo", if_empty );

I disagree.  We need no option to specify this as it is the default if you
don't say to remove files while removing directories.

>  >Those points lead to this progression:
> 
> I think there are actually 16 valid combinations (optional|none, 
> recurse|none, include_files|none, if_empty|none), although 

I wasn't trying to enumerate all combinations, just those related to the
behavior I was discussing.

> two sets of 
> those produce duplicate behavior:
> 
>      remove( "foo");
>      // remove "foo," which must be empty and must exist
> 
>      remove( "foo", including_files );

or     remove("foo", prune);

>      // after removing any files in "foo", remove "foo",
>      // which must not contain any directories and must exist

Oops!  Comments after a thing always throw me for a loop.  Anyway, I guess I
was thinking prune meant remove anything in the directory and its
subdirectories.  IOW, prune == including_files + recurse.

I don't see the value of being able to remove a directory, including any
files it may contain, but throwing an exception if it contains
subdirectories.  The reason to have remove() kill files is to make it easy
to remove a directory and anything it contains.

>      remove( "foo", if_empty );
>      // if empty, remove "foo", which must exist
> 
>      remove( "foo", including_files + if_empty);
>      // after removing any files in "foo", if empty, remove "foo",
>      // which must exist

This is one of those duplicates you referred to, right?  As I see it, this
is the same as if you omit "if_empty."

>      remove( "foo", recurse );
>      // after depth-first recursive removal of any sub-directories,
>      // which must contain no files, remove "foo," which must exist
>      // and must contain no files.

Is there value in this behavior?  Why would one be willing to recursively
remove directories, but not the files within them?

>      remove( "foo", recurse + including_files );
>      // after depth-first recursive removal of any sub-directories,
>      // and any files files they contain, remove "foo," which 
> must exist,
>      // and any files it contains.

I think 'remove("foo", prune)' would cover that nicely.

>      remove( "foo", recurse + if_empty );
>      // after depth-first recursive removal of any empty 
> sub-directories,
>      // remove "foo," which must exist, if it is empty.

You don't say it, but wouldn't this throw an exception if a directory was
not empty?  If so, this is the same as when you omit "if_empty."

>      remove( "foo", recurse + including_files + if_empty);
>      // same as remove( "foo", recurse + including_files );

This again makes "if_empty" superfluous.

I think you're overspecifying the degrees of freedom, thus leading to
duplicate combinations and superfluous options.

Rob
Susquehanna International Group, LLP
http://www.sig.com