Merge pull request #30654 from Microsoft/jjh/unifyworkdir

Windows: Unify workdir handling
Upstream-commit: c3b660b112804dfb1752efc1368a104897c7b884
Component: engine

components/engine/container/container.go

@@ -222,12 +222,6 @@ func (container *Container) SetupWorkingDirectory(rootUID, rootGID int) error {
 
 	container.Config.WorkingDir = filepath.Clean(container.Config.WorkingDir)
 
-	// If can't mount container FS at this point (e.g. Hyper-V Containers on
-	// Windows) bail out now with no action.
-	if !container.canMountFS() {
-		return nil
-	}
-
 	pth, err := container.GetResourcePath(container.Config.WorkingDir)
 	if err != nil {
 		return err

components/engine/container/container_unix.go

@@ -439,12 +439,6 @@ func cleanResourcePath(path string) string {
 	return filepath.Join(string(os.PathSeparator), path)
 }
 
-// canMountFS determines if the file system for the container
-// can be mounted locally. A no-op on non-Windows platforms
-func (container *Container) canMountFS() bool {
-	return true
-}
-
 // EnableServiceDiscoveryOnDefaultNetwork Enable service discovery on default network
 func (container *Container) EnableServiceDiscoveryOnDefaultNetwork() bool {
 	return false

components/engine/container/container_windows.go

@@ -104,13 +104,6 @@ func (container *Container) BuildHostnameFile() error {
 	return nil
 }
 
-// canMountFS determines if the file system for the container
-// can be mounted locally. In the case of Windows, this is not possible
-// for Hyper-V containers during WORKDIR execution for example.
-func (container *Container) canMountFS() bool {
-	return !containertypes.Isolation.IsHyperV(container.HostConfig.Isolation)
-}
-
 // EnableServiceDiscoveryOnDefaultNetwork Enable service discovery on default network
 func (container *Container) EnableServiceDiscoveryOnDefaultNetwork() bool {
 	return true

components/engine/daemon/oci_windows.go

@@ -18,9 +18,9 @@ func (daemon *Daemon) createSpec(c *container.Container) (*specs.Spec, error) {
 		return nil, err
 	}
 
-	if err := c.SetupWorkingDirectory(0, 0); err != nil {
-		return nil, err
-	}
+	// Note, unlike Unix, we do NOT call into SetupWorkingDirectory as
+	// this is done in VMCompute. Further, we couldn't do it for Hyper-V
+	// containers anyway.
 
 	// In base spec
 	s.Hostname = c.FullHostname()

components/engine/docs/reference/builder.md

@@ -1270,19 +1270,6 @@ For example:
 The output of the final `pwd` command in this `Dockerfile` would be
 `/path/$DIRNAME`
 
-On Windows, `WORKDIR` behaves differently depending on whether using Windows
-Server containers or Hyper-V containers. For Hyper-V containers, the engine
-is, for architectural reasons, unable to create the directory if it does not
-previously exist. For Windows Server containers, the directory is created
-if it does not exist. Hence, for consistency between Windows Server and 
-Hyper-V containers, it is strongly recommended to include an explicit instruction
-to create the directory in the Dockerfile. For example:
-
-    # escape=`
-    FROM microsoft/nanoserver
-    RUN mkdir c:\myapp
-    WORKDIR c:\myapp
-
 ## ARG
 
     ARG <name>[=<default value>]

components/engine/integration-cli/docker_cli_run_test.go

@@ -1717,7 +1717,7 @@ func (s *DockerSuite) TestRunWorkdirExistsAndIsFile(c *check.C) {
 	expected := "not a directory"
 	if testEnv.DaemonPlatform() == "windows" {
 		existingFile = `\windows\system32\ntdll.dll`
-		expected = `Cannot mkdir: \windows\system32\ntdll.dll is not a directory.`
+		expected = `The directory name is invalid.`
 	}
 
 	out, exitCode, err := dockerCmdWithError("run", "-w", existingFile, "busybox")