Code looks good, but you should use push -f instead of create a new PR next time.

@keloyang need rebase and CI seems unhappy

integration-cli test pass

04:37:49 OK: 1195 passed, 13 skipped
04:37:49 PASS

but the docker-py failed,maybe we should modify the testcase of docker-py.

@LK4D4 rebased.

Not sure about other contexts, but the windowsTP4 failure is genuine.

I think we'll need to fix docker-py to support this. I'm pretty sure the failing tests are because that library assumes that docker creates the mount points.

ping @hqhq @calavera what's the status here? I see a PR linked from docker-py that was merged?

@keloyang I think you should update the DOCKER_PY_COMMIT in the Dockerfile(s) to fix the tests (https://github.com/docker/docker/blob/master/Dockerfile#L183).

PS: @keloyang if you're short on time, we can carry it for you 😉

@vdemeester I will change it as soon as possible. thank you.

wow - the test failure at https://jenkins.dockerproject.org/job/docs-docker-pr/4223/ is due to alot of commits being merged between the creation of the PR and when the job actually ran - lets see what happens now.

retest this please

the newly triggered checker job failed due to the docker/tutorials repo going private: https://jenkins.dockerproject.org/job/docs-docker-pr/4228/console

WindowsTP4 error looks like an issue with that node; https://jenkins.dockerproject.org/job/Docker-PRs-WoW-TP4/2323/console

08:47:11 
08:47:11 ----------------------------------------------------------------------
08:47:11 FAIL: docker_cli_build_test.go:4270: DockerSuite.TestBuildFromGIT
08:47:11 
08:47:11 docker_cli_build_test.go:4286:
08:47:11     c.Fatal(err)
08:47:11 ... Error: failed to build the image: Sending build context to Docker daemon 50.18 kB

08:47:11 Step 1 : FROM busybox
08:47:11  ---> 19cbf5ea5661
08:47:11 Step 2 : ADD first /first
08:47:11  ---> 2ff8e7df7b98
08:47:11 Removing intermediate container 6a63e7f058d1
08:47:11 Step 3 : RUN [ -f /first ]
08:47:11  ---> Running in 8b1a4f37905c
08:47:11 Cannot start container 8b1a4f37905c410d45d72cfbf143573f72343814243d35cb05bbe7ec428a51f3: HCSShim::StartComputeSystem failed in Win32: The object identifier does not represent a valid object. (0x10d8) id=8b1a4f37905c410d45d72cfbf143573f72343814243d35cb05bbe7ec428a51f3
08:47:11 
08:47:11 

Oh, weird stuff; experimental also actually failed on the docker-py tests, but was marked SUCCESS. Wondering if there's something related to this PR https://jenkins.dockerproject.org/job/Docker-PRs-experimental/16047/console

@thaJeztah, thank you very much, I will check as soon as possible.

Couple of nits.
We should get this in quickly or push off to 1.12 so that we can add explicit create flags before code freeze.

ping @keloyang could you have a look at the comments @cpuguy83 gave? Hopefully we can still get this into 1.11 if those are addressed

Unfortunately, it seems like the cons (breaking change) outweigh the pros of this PR. As far as the create or nocreate options: they are not that useful since if by default we can't break the user, it would have to be a nocreate option, which the user can already do by simply creating the dirs or files beforehand.

Sorry @keloyang it's really not your fault there has been some misunderstanding among maintainers.

I suggest opening another PR to remove the deprecation in the docs and the warning as well.

I have a need in which I'm fairly certain there is no solution without a nocreate option. I have a script that run a docker-in-docker container, passing the script's arguments into a script in that container, and that container script starts other docker containers. I pass in the hosts cwd as an environment variable. The container script is smart enough to parse the arguments passed in, but the host script that starts all of this is not. The container script is going to start sibling containers since docker.sock is mounted and it mounts volumes with docker run based on the arguments passed in. However, the container script can't determine if volumes already exist (that I know of). That means that if a non-existent directory path is passed to the host script as an argument, my docker run command is going to use it whether it exists or not, and thus it will be created on the host. Lacking nocreate, my script has the unfortunate flaw of creating directories when a non-existent path is given.

My usecase would benefit from the nocreate option. I have a container deployed on an embedded system, and if a directory doesn't exist, that means a prior mount has failed. Docker would happilly create the dir off the mount, and fill the root partition with data :(

@YarekTyshchenko you can use the "advanced" syntax --mount flag instead, which does not auto-create the path; see https://docs.docker.com/storage/bind-mounts/

$ docker run --rm --mount type=bind,src=/no/such/dir,target=/container/path alpine
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /no/such/dir.

@thaJeztah I unfortunately don't have access to the command directly. It runs as part of microsoft's Azure IoT Edge offering.
https://docs.microsoft.com/en-us/azure/iot-edge/how-to-access-host-storage-from-module?view=iotedge-2020-11
I will check the integration to see if there is a syntax that i've missed.