Useful or not, from you.
ccache Util::make_relative_path test case fails on Windows

The modified Util::make_relative_path implementation added in 8223ed38abd9cf75ab75cb19dc2081c44bf568d0 seems to have introduced some some test failures on Windows when I run the unit tests locally.

I suspect this is in part due to make_relative_path calling Stat::same_inode_as, which gives incorrect results on Windows because st_ino is not populated by the stat() implementation in either the legacy msvcrt.dll (still used by mingw-w64) or ucrtbase.dll (used by Visual Studio).

Note that st_dev is populated with a distinct value for each Win32 drive letter, so Stat::same_inode_as can distinguish between two files on different drives, but that's it. I suspect these failures are not seen in CI because the GitHub runners use a working directory not under the C:\ drive to check out the repo and run the tests.

> .\unittest\unittest.exe
[doctest] doctest version is "2.4.5"
[doctest] run with "--help" for options
===============================================================================
../unittest/test_Util.cpp:564:
TEST SUITE: Util
TEST CASE:  Util::make_relative_path
  Path matches neither actual nor apparent CWD

../unittest/test_Util.cpp:593: ERROR: CHECK( make_relative_path("C:/", "C:/a", "C:/b", "C:/x") == "C:/x" ) is NOT correct!
  values: CHECK( ..x == C:/x )

===============================================================================
[doctest] test cases:  151 |  150 passed | 1 failed | 0 skipped
[doctest] assertions: 2196 | 2195 passed | 1 failed |
[doctest] Status: FAILURE!
Note: Test data has been left in testdir/6332

How to reproduce

Run unit tests on Windows; current working directory should be under c:\

Actual behavior

Util::make_relative_path test case fails since 8223ed38abd9cf75ab75cb19dc2081c44bf568d0

Expected behavior

All unit tests pass

Environment

<!-- Which ccache version did you use? -->

ccache version 4.1-dev (97a40af49f56e4be2db5e4318d8131e937bd5598) Compiler: mingw-w64 GCC-8.1.0

That's a useful answer
Without any help

@nickhutchinson: Was this fixed by #819?

Yes - this can be closed now