https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Tom Allen from comment #4)
> 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().
I don't think that's quite true. You can still use filesystem::copy, you just
need to use copy_options specific to the file type. So iterate over the
directory contents and for directories, call filesystem::copy with no
arguments, and for files, call filesystem::copy with update_existing /
overwrite_existing.
> That seems like a strange asymmetry compared to the recursive
> call.
For a recursive call, passing copy_options that only make sense for files is
useful, because there could be files somewhere in a sub-dir that you want to
copy. Passing those when copying just a directory, without recursing, isn't
useful.
For a shallow, non-recursive copy, I think it makes sense that you would have
to call copy for each file individually, and if you're already doing that, it's
not such a stretch to use arguments specific to the file type.
In any case, that's what the standard says, so it's not a GCC bug.
If you think this is a defect in the standard then report it to the committee
instead: https://cplusplus.github.io/LWG/lwg-active.html#submit_issue
