Summary
On Windows, an absolute host bind mount like volume=C:\data:/var/lib/data does not work. eph treats it as a named volume rather than a host bind, and the drive-letter colon breaks the spec split.
Split off from #44 (which fixed the separate relative-bind \?\ issue). These are distinct bugs; #44's fix is complete without this.
Diagnosis
resolve_volume_spec (src/service.rs) decides host-path vs named-volume by whether the spec starts with / or .:
if spec.starts_with('/') || spec.starts_with('.') {
// host-path bind mount
} else {
// named volume, namespaced
}
An absolute Windows path starts with a drive letter (C), not / or ., so C:\data:/var/lib/data falls into the named-volume branch. On top of that, the spec is split with splitn(2, ':'), which lands on the drive-letter colon:
"C:\data:/var/lib/data" splits into ["C", "\data:/var/lib/data"]
So the "volume name" becomes C and the "container path" becomes \data:/var/lib/data. The result is a bogus namespaced named volume, not the intended host bind. A verbatim \?\C:\... absolute source has the same problem (starts with \, drive colon inside).
Proper fix
This needs a real volume-spec parser rather than splitn(2, ':'), one that understands Windows drive letters (X:\...), the \?\ and UNC forms, and the [host]:[container][:mode] shape with a Windows-aware split (Docker's own client special-cases a single leading drive letter before splitting on :). A drive-letter or backslash prefix should route to the host-path branch, and the split must not treat the drive colon as the host/container separator.
Repro
[svc]
image=alpine
volume=C:\Users\me\data:/data
Expected: C:\Users\me\data bind-mounted at /data. Actual: a namespaced named volume derived from C is created instead.
Scope note
Relative binds (./seed:/x) and Unix-style absolute binds (/host/path:/x) are unaffected and work today. This is specifically about Windows drive-letter absolute sources.
Summary
On Windows, an absolute host bind mount like
volume=C:\data:/var/lib/datadoes not work. eph treats it as a named volume rather than a host bind, and the drive-letter colon breaks the spec split.Split off from #44 (which fixed the separate relative-bind
\?\issue). These are distinct bugs; #44's fix is complete without this.Diagnosis
resolve_volume_spec(src/service.rs) decides host-path vs named-volume by whether the spec starts with/or.:An absolute Windows path starts with a drive letter (
C), not/or., soC:\data:/var/lib/datafalls into the named-volume branch. On top of that, the spec is split withsplitn(2, ':'), which lands on the drive-letter colon:"C:\data:/var/lib/data"splits into["C", "\data:/var/lib/data"]So the "volume name" becomes
Cand the "container path" becomes\data:/var/lib/data. The result is a bogus namespaced named volume, not the intended host bind. A verbatim\?\C:\...absolute source has the same problem (starts with\, drive colon inside).Proper fix
This needs a real volume-spec parser rather than
splitn(2, ':'), one that understands Windows drive letters (X:\...), the\?\and UNC forms, and the[host]:[container][:mode]shape with a Windows-aware split (Docker's own client special-cases a single leading drive letter before splitting on:). A drive-letter or backslash prefix should route to the host-path branch, and the split must not treat the drive colon as the host/container separator.Repro
Expected:
C:\Users\me\databind-mounted at/data. Actual: a namespaced named volume derived fromCis created instead.Scope note
Relative binds (
./seed:/x) and Unix-style absolute binds (/host/path:/x) are unaffected and work today. This is specifically about Windows drive-letter absolute sources.