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