Detect Windows absolute paths on non-Windows CLI#1990
Detect Windows absolute paths on non-Windows CLI#1990silvin-lubecki merged 1 commit intodocker:masterfrom
Conversation
|
ping @silvin-lubecki @vdemeester @ddebroy PTAL |
|
Ah, booh! The linter doesn't like the Golang standard library; |
ea9fac0 to
af38be8
Compare
Codecov Report
@@ Coverage Diff @@
## master #1990 +/- ##
==========================================
+ Coverage 56.74% 56.78% +0.04%
==========================================
Files 310 311 +1
Lines 21802 21832 +30
==========================================
+ Hits 12371 12398 +27
- Misses 8517 8519 +2
- Partials 914 915 +1 |
|
|
||
| // volumeNameLen returns length of the leading volume name on Windows. | ||
| // It returns 0 elsewhere. | ||
| // nolint: gocyclo |
There was a problem hiding this comment.
Added this to silence the linter
cli/compose/loader/loader_test.go
Outdated
| image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 | ||
| volumes: | ||
| - type: bind | ||
| source: c:\ |
There was a problem hiding this comment.
Just to be safe, can the unit tests use E:\ or X:\ as the source path's drive (something other than C:\) in some of the cases?
There was a problem hiding this comment.
Yes, I can change that; let me update
43574ef to
72bb085
Compare
vdemeester
left a comment
There was a problem hiding this comment.
LGTM 🐯
/cc @simonferquel
72bb085 to
d760466
Compare
|
Per discussion with @silvin-lubecki on slack: I removed the redundant |
|
Booh; this one starts failing now all of a sudden; #1841 (comment) |
When deploying a stack using a relative path as bind-mount source in the compose file, the CLI converts the relative path to an absolute path, relative to the location of the docker-compose file. This causes a problem when deploying a stack that uses an absolute Windows path, because a non-Windows client will fail to detect that the path (e.g. `C:\somedir`) is an absolute path (and not a relative directory named `C:\`). The existing code did already take Windows clients deploying a Linux stack into account (by checking if the path had a leading slash). This patch adds the reverse, and adds detection for Windows absolute paths on non-Windows clients. The code used to detect Windows absolute paths is copied from the Golang filepath package; https://github.com/golang/go/blob/1d0e94b1e13d5e8a323a63cd1cc1ef95290c9c36/src/path/filepath/path_windows.go#L12-L65 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
d760466 to
d6dd08d
Compare
Note that there is an alternative PR in #1871, but that PR changes the current behaviour, and might require more discussion. This PR tries to focus on just the basic problem.
addresses #1403
addresses moby/moby#33746
fixes moby/moby#34810
When deploying a stack using a relative path as bind-mount source in the compose file, the CLI converts the relative path to an absolute path, relative to the location of the docker-compose file.
This causes a problem when deploying a stack that uses an absolute Windows path, because a non Windows client will fail to detect that the path (e.g.
C:\somedir) is an absolute path (and not a relative directory namedC:\).The existing code did already take Windows clients deploying a Linux stack into account (by checking if the path had a leading slash). This patch adds the reverse, and adds detection for Windows absolute paths on non-Windows clients.
The code used to detect Windows absolute paths is copied from the Golang filepath package;
https://github.com/golang/go/blob/1d0e94b1e13d5e8a323a63cd1cc1ef95290c9c36/src/path/filepath/path_windows.go#L12-L65
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)