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.

             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).