public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "fabian@ritter-vogt.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/99290] New: std::filesystem::copy does not always report errors for recursion
Date: Fri, 26 Feb 2021 15:42:52 +0000 [thread overview]
Message-ID: <bug-99290-4@http.gcc.gnu.org/bugzilla/> (raw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99290
Bug ID: 99290
Summary: std::filesystem::copy does not always report errors
for recursion
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fabian@ritter-vogt.de
Target Milestone: ---
For the case where a directory is copied to another directory with either
copy_options::recursive or copy_options::none, fs_copy.cc has this in
std::filesystem::copy:
for (const directory_entry& x : directory_iterator(from))
copy(x.path(), to/x.path().filename(), options, ec);
This does not check the value of "ec" after each call to copy. As successful
invocations of copy clear the error, only the last call to copy influences the
error code. As the order of entries returned by directory_iterator is
unspecified, it's also unspecified whether an error is reported if recursive
copying fails.
Test program:
#include <filesystem>
int main(int argc, char *argv[])
{
std::filesystem::copy(std::filesystem::path{argv[1]},
std::filesystem::path{argv[2]},
std::filesystem::copy_options::none);
}
Compile and run like this:
> g++ fstest.cpp -std=c++17 -o fstest # Compile
> mkdir source dest
> mkdir source/emptydir dest/emptydir # Empty directories, noop for fs::copy
> touch source/file; echo "dst" > dest/file # Conflicting files to make fs::copy fail
> ./fstest source dest # Doesn't fail, because the empty directories overwrote the error code
> rmdir source/emptydir dest/emptydir # Drop the empty directories
> ./fstest source dest # Now it fails
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot copy: File exists [source] [dest]
Whether you see the same effect is highly dependent on your (file) system.
next reply other threads:[~2021-02-26 15:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-26 15:42 fabian@ritter-vogt.de [this message]
2021-02-26 15:49 ` [Bug libstdc++/99290] " marxin at gcc dot gnu.org
2022-04-28 12:33 ` cvs-commit at gcc dot gnu.org
2022-04-28 13:31 ` redi at gcc dot gnu.org
2022-04-28 17:04 ` cvs-commit at gcc dot gnu.org
2022-04-28 17:05 ` redi at gcc dot gnu.org
2022-06-14 19:20 ` cvs-commit at gcc dot gnu.org
2022-06-14 19:21 ` redi at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-99290-4@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).