Allow linux like paths in volume source on Windows

[AceHack]

I would expect the following two docker-compose files to work exactly the same but they do not. The first one works with C:/ but the second one with just / does not. In most other places in docker like Dockerfiles, Linux like paths can be used with no issues.

Works:

version: '3.3'
services:
  arch.samples.containers:
    volumes:
    - type: bind
      source: ${ArchSamplesContainersConfigPath-C:/etc/Arch.Samples.Containers}
      target: /etc/Arch.Samples.Containers
      read_only: true
      volume:
        nocopy: true

Does not work:

version: '3.3'
services:
  arch.samples.containers:
    volumes:
    - type: bind
      source: ${ArchSamplesContainersConfigPath-/etc/Arch.Samples.Containers}
      target: /etc/Arch.Samples.Containers
      read_only: true
      volume:
        nocopy: true

Fails with "Cannot create container for service arch.samples.containers: invalid mount config for type "bind": bind source path does not exist"

Docker Version:
Client:
Version: 18.02.0-ce
API version: 1.36
Go version: go1.9.3
Git commit: fc4de44
Built: Wed Feb 7 21:12:53 2018
OS/Arch: windows/amd64
Experimental: true
Orchestrator: kubernetes

Server:
Engine:
Version: 18.02.0-ce
API version: 1.36 (minimum version 1.12)
Go version: go1.9.3
Git commit: fc4de44
Built: Wed Feb 7 21:20:15 2018
OS/Arch: linux/amd64
Experimental: true

docker-compose version 1.19.0, build 9e633ef
docker-py version: 2.7.0
CPython version: 2.7.14
OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017

Windows Version:
Windows 10 Build 17107.rs4_release.180220-1350

[davclark]

This is the closest I've found to an issue talking about paths on docker, and I'm hoping the folks working on it will know enough to resolve the cross-project issues that have me confused. Just to make the confusion explicit:

Inside the Hyper-V VM that actually runs the docker daemon (already, I'm not sure that's reality...), there are mounts to the host filesystems that look like /c and /C. Somehow, paths that start that way for docker-compose volume mounts used to work. I am not sure if that's because they were understood to refer to host paths, or because they resolved directly to paths inside the docker daemon VM (Moby?).

Paths that start with C:\ also seemed to work, at least for a while.

Paths that ONLY exist inside the docker daemon VM also used to work in docker-compose (e.g., /var/run/docker.sock). Now, unless we explicitly set COMPOSE_CONVERT_WINDOWS_PATHS=1, those slashes get converted into backslashes (maybe doubled up due to faulty escape rules). This is documented in docker/for-win#1829.

What is doing this path re-writing? It seems like maybe it's happening redundantly at a couple of layers. In particular, setting COMPOSE_CONVERT_WINDOWS_PATHS seems to disable certain path re-writing rules. In any case, probably we don't want to convert paths that are meant to refer to something inside the docker VM.

This is important to understand if you are supporting people that will simply upgrade to the most recent stable version of Docker!