Ok, first, I admit that I was not familiar with the details of std::filesystem. However, after
looking at it, I remain unsurprised that the Cygwin and Mingw versions might be different. (I would
also not be surprised if there is a real bug in there.) The behavior I would _expect_ is that the
Cygwin version will work using Posix sorts of assumptions. While a root of C: (for example) _might_
work, /cygdrive/c is more normative on Cygwin. (I put a link to that in Cygwin's / called c, so
that, for me, /c works.) Likewise, I would expect the normative path separator to be / not \, and
an absolute path to start with /. Windows offers several kinds of symlinks, with varying semantics,
so the detailed behavior of that would be affected by the settings in the CYGWIN environment variable.
I would expect std::filesystem to present paths to construct paths to present to underlying library
calls such as open ... and on Cygwin, open uses Posix style paths.
I "get" that you want to write portable programs that use this interface, which is analogous to the
Java file path classes. In terms of how this interface works, I would expect it to _claim_ that it
is Posix, not Windows, because the paths Cygwin supports are Posix style (it _will_ recognize a few
Windows idioms, but it is correct in not advertising itself as Windows).
So it you want to do Windows-style (but abstracted with this library), I direct you to Mingw. Each
has its place. Cygwin allows one to pretend, pretty successfully though with a few small rough
edges, that one is on Linux, not Windows. That is its intent. Mingw gives you the gcc/gnu
toolchain and libraries under Windows.
I hope we're not still talking at cross purposes, though that it certainly
possible!
Best wishes - EM
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
