MountableFile path resolving on Windows buggy

[glebsts]

Added new test into MountableFileTest.java

@Test
public void forHostFileOnWindows() throws Exception {
    final Path file = createTempFile("somepath");
    final MountableFile mountableFile = MountableFile.forHostPath(file.toString());
    /* taken from performChecks() */
    final String mountablePath = mountableFile.getResolvedPath();
    /* fails here */
    assertTrue("The resolved path can be found", new File(mountablePath).exists());
}

On Windows resolved path becomes mingw-fied as //c/something/filename.ext and File API does not understand it.
That results in files being copied with null-length i.e. when packing tar archive with files to copy to container. Header for file is created, but content is not written.

What's the idea behind mingw-fying file path?

[glebsts]

PR #445 please review.

[rnorth]

Thanks @glebsts, and sorry for not responding sooner. Re scope of testing on Windows, it's unfortunately not something we run automated tests on yet. As far as we're aware there are no cloud testing options that support use of docker on a windows host, so the only option seems to be physical hardware - which takes quite a bit more effort to set up. I need to give this some attention, though.

Will review.

[glebsts]

Thank you @rnorth . Yes, I seem to be the only freak here with "alternative operating system", but I enjoy being a rebel. So far I have to use local patched version, as quite many changes were done :). Will make new PRs. Still not able to use docker-compose with testcontainers.

Just randomly found that in google. Not sure if free, or suits you at all, probably you've seen that.
https://stefanscherer.github.io/setup-windows-docker-ci-appveyor/

[rnorth]

Thanks @glebsts. I'll have a look - I'm aware of at least two attempts to use Appveyor for testcontainers, but based on that post maybe they've changed their support for Docker!

[glebsts]

@rnorth I really hope that will get some review and approval, as I would like to add another PR (about #446 ) on top of that.

[jaagupkymmel]

@rnorth Please find the time to review this, I'm waiting for this fix too.