[libcxx-dev] Testing std::filesystem on Windows

[Louis Dionne via libcxx-dev]

> On Oct 16, 2020, at 06:19, Martin Storsjö via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> As a prerequisite to being able to implement std::filesystem for windows in libc++ (something that I guess there's more or less desire to do), the first step would be to make the existing tests work on windows.
> 
> There already exists two other implementations of std::filesystem on windows; Microsoft's STL and libstdc++ for mingw. While there are certain corner case differences in how they behave, they agree on most of the vital points.
> 
> There are a couple things that differ pretty significantly in std::filesystem on Windows on these implementations, compared to other platforms and implementations, and most of these differenes are mandated:
> 
> - fs::path::value_type is wchar_t, and fs::path::string_type is std::wstring. This requires a bit of touch-ups here and there; some are pretty straightforward (just using the right fs::path::*_type instead of hardcoding char/string), but some require a bit more conversion, as a lot of the code in the testsuite really wants to work on test data in std::string form. Instead of forcing everything to agnostic form, I'm often using the string() method to specifically request a std::string.

Let's fix those.

> 
> - preferred_separator is \ instead of /. This pops up in a few tests that do path adjustments. When comparing two fs::path objects using operator==, two paths are considered equal even if they have different separators, but some of the tests use a function PathEq(), that check for exact equality. For those cases, I've changed some occurrances of PathEq() into operator==.

Same.

> 
> - Many tests want to set permission::none on a directory, in order to make accesses fail, to test for different error cases. Setting permission::none doesn't really work in windows, at least not with the two tested implementations

Let's find another way to write those tests. They also cause all kinds of issues when running the tests as a root user, and also when running the tests from elsewhere than /tmp. Even after playing around a bit, I don't understand exactly what's special with /tmp that makes these tests pass, but it's really annoying that they're relying on that.

> 
> - Tests that look for specific error codes often fail, but I guess this can be seen as a shortcoming in these implementations.
> 
> - While Windows does support symlinks, it's rather limited. (Only processes with elevated privileges can create symlinks, or normal processes can create symlinks on Windows 10 if developer mode is enabled and a special flag is included in the function call to create them.) For now I've just ifdeffed out those bits of the tests (which is a pretty big bit), but I guess I should revisit those bits before trying to upstream those parts.
> 
> - Windows filesystem timestamps (and both MS STL and libstdc++) use a 100 nanosecond timebase, with a different epoch than the regular time_t epoch used in values returned by stat().
> 
> 
> I've got a patchset locally that makes all tests pass, by either fixing things, or disabling tests that assume thigs that the implementations don't provide. I'll start by trying to upstream the more central and less dirty bits, to get the ball rolling.

Excellent, thanks for working on this. If the filesystem tests pass on Windows and with libstdc++, it means they might have an incentive to contribute to the test suite.

Louis