If .dockerignore mentions either then the client will send them to the
daemon but the daemon will erase them after the Dockerfile has been parsed
to simulate them never being sent in the first place.
an events test kept failing for me so I tried to fix that too
Closes#8330
Signed-off-by: Doug Davis <dug@us.ibm.com>
Fixes#1992
Right now when you `docker cp` a path which is in a volume, the cp
itself works, however you end up getting files that are in the
container's fs rather than the files in the volume (which is not in the
container's fs).
This makes it so when you `docker cp` a path that is in a volume it
follows the volume to the real path on the host.
archive.go has been modified so that when you do `docker cp mydata:/foo
.`, and /foo is the volume, the outputed folder is called "foo" instead
of the volume ID (because we are telling it to tar up
`/var/lib/docker/vfs/dir/<some id>` and not "foo", but the user would be
expecting "foo", not the ID
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Volume refs were not being restored on daemon restart.
This made it possible to remove a volume being used by other containers
after a daemon restart.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Also wrap access in mutex.
Makes sure we don't have any pontential for races in accessing this.
It also doesn't really need to be/shouldn't be in the config.json anyway
Docker-DCO-1.1-Signed-off-by: Brian Goff <bgoff@cpuguy83-mbp.home> (github: cpuguy83)
volumes.Get was not checking for symlinked paths meanwhile when adding a
new volume it was following the symlink.
So when trying to use a bind-mount that is a symlink, the volume is
added with the correct path, but when another container tries to use the
same volume it got a "Volume exists" error because volumes.Get returned
nil and as such attempted to create a new volume.
Docker-DCO-1.1-Signed-off-by: Brian Goff <cpuguy83@gmail.com> (github: cpuguy83)
