From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3675B3858407; Tue, 13 Sep 2022 21:43:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3675B3858407 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663105408; bh=ww00qY2CNWhW7ufNwjYBxNqduwnIauoUASBYWy0ELJ8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VsMRWq9bS5LbJXbHJdhrwxIQDvypnb8dZeuAmYpKLw5J9Lw60+HUFEVO/tanu62+B ZCjbAl6BEU2X2EUEXr2m3bkdSTD9EVHA8/v25+NPGVVsZ5b1u01FtA77LnI9QQbCEg htkmkSNDk7B5iW19Dei4tEqufqzDcIPkoHcb4xzs= From: "thomas.allen at intel dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options Date: Tue, 13 Sep 2022 21:43:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 11.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: thomas.allen at intel dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106932 --- Comment #6 from Tom Allen --- (In reply to Jonathan Wakely from comment #5) > (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 w= hich > > I do want to overwrite in their destinations, there is no way to perfor= m the > > operation unless I manually iterate and check file types, then call > > copy_file(). >=20 > 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. >=20 > > That seems like a strange asymmetry compared to the recursive > > call. >=20 > 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. >=20 > 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. >=20 > In any case, that's what the standard says, so it's not a GCC bug. >=20 > 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 In this case, would it be possible to add a warning to the compiler for this usage? Even with -Wall -Wextra it's silent, and since it functions as a no-= op, it's somewhat confusing to track down.=