Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect Windows absolute paths on non-Windows CLI #1990

Merged
merged 1 commit into from
Jul 11, 2019

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Jul 9, 2019

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 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

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

@thaJeztah
Copy link
Member Author

ping @silvin-lubecki @vdemeester @ddebroy PTAL

/cc @stevenfollis @david-yu @ivansharamok

@thaJeztah
Copy link
Member Author

Ah, booh! The linter doesn't like the Golang standard library;

cli/compose/loader/windows_path.go:35::warning: cyclomatic complexity 18 of function volumeNameLen() is high (> 16) (gocyclo)

@codecov-io
Copy link

codecov-io commented Jul 9, 2019

Codecov Report

Merging #1990 into master will increase coverage by 0.04%.
The diff coverage is 90.32%.

@@            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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this to silence the linter

Copy link

@ddebroy ddebroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with a couple of suggestions that can be addressed later

image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
volumes:
- type: bind
source: c:\
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I can change that; let me update

cli/compose/loader/windows_path.go Outdated Show resolved Hide resolved
@thaJeztah thaJeztah force-pushed the cross_platform_bind branch 2 times, most recently from 43574ef to 72bb085 Compare July 9, 2019 23:14
Copy link
Collaborator

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🐯
/cc @simonferquel

@thaJeztah
Copy link
Member Author

Per discussion with @silvin-lubecki on slack: I removed the redundant path.IsAbs from the isAbs() function, and updated the test-file to also include the copyright from upstream

@thaJeztah
Copy link
Member Author

Booh; this one starts failing now all of a sudden; #1841 (comment)

10:06:29 === FAIL: e2e/container TestSigProxyWithTTY (6.52s)
10:06:29     proxy_signal_test.go:38: terminating PID 3438
10:06:29     proxy_signal_test.go:42: timeout hit after 5s: expected status exited != running

Copy link
Contributor

@silvin-lubecki silvin-lubecki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

docker stack deploy prepends current Unix dir to Windows bind mount source
6 participants