From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 9A4573858407; Tue, 13 Sep 2022 20:34:22 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9A4573858407
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1663101262;
	bh=FZr03qnwfI6jnRdyNlmoVoh4mgZSDUSzuJHQb7+ojOI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=cTHzmk+mrY21qDzPb90IOPYT2JnNmpvMj4oNksmdHlsmVXhXfZS/3vHgVj3bAyA+J
	 OrackYSU1vMarfSmGGVoO7RNxY9u9p8B2uAjxLe7d+IPODCsvd0hKym1phM5rM3cd7
	 AiE4Y5C6iC9SS9OFIusUtMty1QLdutYulXIKKWdg=
From: "thomas.allen at intel dot com" <gcc-bugzilla@gcc.gnu.org>
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 20:34:22 +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: UNCONFIRMED
X-Bugzilla-Resolution: 
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: <bug-106932-4-Qm3sfXYbBU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106932-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106932-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106932

--- 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.
>=20
> Where f is status("source") and t is status("dest").
>=20
> Effects are then as follows:
>=20
> - If f.type() or t.type() is an implementation-defined file type ...
>=20
> [they're not]
>=20
> - Otherwise, an error is reported as specified in 31.12.5 if:
>=20
> [list of conditions that are not true]
>=20
> - Otherwise, if is_symlink(f), then:
>=20
> [it's not]
>=20
> - Otherwise, if is_regular_file(f), then:
>=20
> [it's not]
>=20
> - Otherwise, if
>   is_directory(f) &&
>   (options & copy_options::create_symlinks) !=3D copy_options::none
>=20
> [create_symlinks is not set in the options]
>=20
> - Otherwise, if
>   is_directory(f) &&
>   ((options & copy_options::recursive) !=3D copy_options::none ||
>     options =3D=3D copy_options::none)
>=20
> [this is the case we want to hit, but the condition is false because
> recursive is not set and options !=3D none]
>=20
> - Otherwise, for the signature with argument ec, ec.clear().
>=20
> [You didn't pass an erroc_code]
>=20
> - Otherwise, no effects.
>=20
> [Bingo]
>=20
> 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.=