Differences to Standard Filesystem Implementations

Differences Between Actual std::filesystem Implementations and ghc::filesystem

This page tries to collect test cases from the unit tests that currently fail when run against an existing C++17 std::filesystem implementation of more current enough compilers.

30.10.8.4.6 path native format observers [fs.path.native.obs]

  CHECK( fs::u8path("\xc3\xa4/\xe2\x82\xac\xf0\x9d\x84\x9e").u16string() == std::u16string(u"\u00E4/\u20AC\U0001D11E") )
due to unexpected exception with messages:
  filesystem error: Cannot convert character sequence: Illegal byte sequence

GCC 8.2.0: I had observed this on gcc from brew on macOS. The compiler doesn't recognize the valid Unicode codepoint U+1D11E.

30.10.15.3 copy [fs.op.copy]

  REQUIRE_NOTHROW( fs::copy("dir1", "dir3", fs::copy_options::create_symlinks | fs::copy_options::recursive) )
due to unexpected exception with message:
  filesystem error: in copy: Is a directory [dir1] [dir3]

Clang++ 7, GCC 8: The compilers complain about a copy call with fs::copy_options::recursive combined with fs::copy_options::create_symlinks or fs::copy_options::create_hard_links if the source is a directory. There is nothing in the standard that forbids this combination and it is the only way to deep-copy a tree while only create links for the files. There is LWG #2682 that supports this interpretation, but the issue ignores the usefulness of the combination with recursive and part of the justification for the proposed solution is "we did it so for almost two years". But this makes fs::copy with fs::copy_options::create_symlinks or fs::copy_options::create_hard_links just a more complicated syntax for the fs::create_symlink or fs::create_hardlink operation to create a single link. I'm not sure, if that was the intention of the original writing. As there is another issue related to copy, with a different take on the description, I keep my version the way I read the description, as it is not contradicting the standard and useful. I might need to change that, if the final solution the LWG comes up with will lead to a definitive wording in the standard.