https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932
--- Comment #4 from Tom Allen <thomas.allen at intel dot com> ---
(In reply to Jonathan Wakely from comment #2)
> I think this is the correct behaviour according to the standard.
>
> Where f is status("source") and t is status("dest").
>
> Effects are then as follows:
>
> - If f.type() or t.type() is an implementation-defined file type ...
>
> [they're not]
>
> - Otherwise, an error is reported as specified in 31.12.5 if:
>
> [list of conditions that are not true]
>
> - Otherwise, if is_symlink(f), then:
>
> [it's not]
>
> - Otherwise, if is_regular_file(f), then:
>
> [it's not]
>
> - Otherwise, if
> is_directory(f) &&
> (options & copy_options::create_symlinks) != copy_options::none
>
> [create_symlinks is not set in the options]
>
> - Otherwise, if
> is_directory(f) &&
> ((options & copy_options::recursive) != copy_options::none ||
> options == copy_options::none)
>
> [this is the case we want to hit, but the condition is false because
> recursive is not set and options != none]
>
> - Otherwise, for the signature with argument ec, ec.clear().
>
> [You didn't pass an erroc_code]
>
> - Otherwise, no effects.
>
> [Bingo]
>
> So you need to use copy_options::recursive to get the effects you want.
If this is the case, then when I have subdirectories which I explicitly do not
want to copy, but files at the same level in the source directory which I do
want to overwrite in their destinations, there is no way to perform the
operation unless I manually iterate and check file types, then call
copy_file(). That seems like a strange asymmetry compared to the recursive
call.
