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>
Upstream-commit: ef98fe0763024abd90bd5a573fec816895ee92e4
Component: engine
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>
Upstream-commit: 9acf7c765c7e074f6c75eaf162ca06ecfe40d692
Component: engine
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)
Upstream-commit: c5e728c953e29b8008cdfb8367910e33ba28b99c
Component: engine
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)
Upstream-commit: 882223c0f8a55c2011277aba08f1487a2930c075
Component: engine
