public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/99533] New: "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
@ 2021-03-10 23:04 ssh at pobox dot com
  2021-03-11 13:12 ` [Bug libstdc++/99533] " redi at gcc dot gnu.org
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: ssh at pobox dot com @ 2021-03-10 23:04 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 99533
           Summary: "operation not permitted" error on
                    recursive_directory_iterator despite
                    skip_permission_denied
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ssh at pobox dot com
  Target Milestone: ---

On POSIX filesystem backend type systems the
std::filesystem::recursive_directory_iterator throws a filesystem_error
exception with "operation not permitted" when the opendir/readdir call returns
EPERM instead of EACCES even if
std::filesystem::directory_options::skip_permission_denied is set.

Given the following code:

#include <iostream>
#include <filesystem>

int main(int argc, char* argv[])
{
    fs::path dir{"."};
    if(argc == 2) {
        dir = fs::u8path(argv[1]);
    }

    int totalDirs = 0;
    int totalFiles = 0;
    try {
        for(const auto& de : fs::recursive_directory_iterator(dir,
fs::directory_options::skip_permission_denied)) {
            if(de.is_regular_file()) {
                ++totalFiles;
            }
            else if(de.is_directory()) {
                ++totalDirs;
            }
        }
    }
    catch(fs::filesystem_error fe) {
        std::cerr << "Error: " << fe.what() << std::endl;
        exit(1);
    }
    std::cout << totalFiles << " files in " << totalDirs << " directories" <<
std::endl;
    return 0;
}

This fails for example on macOS when called on the user home directory with:

Error: filesystem error: cannot increment recursive directory iterator:
Operation not permitted

This is due to System Integrity Protection (since macOS 10.14) on the
"/Users/<user>/Library/Application Support/MobileSync" folder leading to EPERM.

On Linux, called with / it stops when hitting for example a
"/proc/1/task/1/cwd", resulting in EPERM too.

I don't have examples from other POSIX systems, but I would say handling only
EACCES  for the skip_permission_denied option is not enough.

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-12-19 21:55 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-10 23:04 [Bug libstdc++/99533] New: "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied ssh at pobox dot com
2021-03-11 13:12 ` [Bug libstdc++/99533] " redi at gcc dot gnu.org
2021-03-11 13:15 ` redi at gcc dot gnu.org
2021-03-11 15:06 ` redi at gcc dot gnu.org
2021-03-11 18:21 ` redi at gcc dot gnu.org
2021-03-14  7:05 ` ssh at pobox dot com
2021-03-29 20:03 ` cvs-commit at gcc dot gnu.org
2021-03-29 21:37 ` redi at gcc dot gnu.org
2021-04-20 18:52 ` cvs-commit at gcc dot gnu.org
2021-04-20 18:53 ` redi at gcc dot gnu.org
2022-12-19 21:55 ` redi at gcc dot gnu.org

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