Make container.Copy support volumes#8509
Conversation
|
@cpuguy83 ❤️ |
cpuguy83
force-pushed
the
make_copy_support_volumes
branch
from
edeee39 to
cb66e9f
Compare
|
❤️ |
cpuguy83
force-pushed
the
make_copy_support_volumes
branch
from
cb66e9f to
12290e2
Compare
|
❤️ |
|
Also, I want to say that |
daemon/container.go
Outdated
There was a problem hiding this comment.
I don't like this change. This variable used only in TarWithOptions and without this change I saw that this is just Compression and Includes, now I need to look all code between this line and TarWithOptions to be sure that there is no other things in opts.
There was a problem hiding this comment.
That's fine, I originally had this implemented differently and needed it moved up (or rather wanted it), but don't need to anymore.
I'll fix.
cpuguy83
force-pushed
the
make_copy_support_volumes
branch
from
12290e2 to
e4b9f25
Compare
|
@LK4D4 Updated. |
There was a problem hiding this comment.
do we need to check the length here? what if its 0, I know it shouldn't ever be buttt...
There was a problem hiding this comment.
length of? resource?
In a way it is checking because the length of the mountToPath couldn't be 0.
There was a problem hiding this comment.
ok as long as mountToPath could never be 0, bc of the slice I was just worried about a panic :) but good to know
There was a problem hiding this comment.
Good point, it may be worth it to check just in case.
|
LGTM |
daemon/container.go
Outdated
There was a problem hiding this comment.
checking the length of MountToPath here then would suffice sense it gets passed to Export
cpuguy83
force-pushed
the
make_copy_support_volumes
branch
from
e4b9f25 to
d0a50df
Compare
|
👍 |
cpuguy83
force-pushed
the
make_copy_support_volumes
branch
from
d0a50df to
36102c1
Compare
Fixes moby#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 <[email protected]>
cpuguy83
force-pushed
the
make_copy_support_volumes
branch
from
36102c1 to
ef98fe0
Compare
|
Commit message helped a lot. |
Make container.Copy support volumes
|
OI! Where's the documentation for this change? |
|
@SvenDowideit docs were probably copied from a volume using the previous build? 😉 |
Signed-off-by: Brian Goff <[email protected]>
Add missing docs for #8509
Signed-off-by: Brian Goff <[email protected]>
This commit brings two main changes, notably:
Two new options that can be set as environment variables
- DOCKER_OPTS: any arbitrary set of docker options. Example: --tlsverify
- DOCKER_NATIVE: This forces the use of the native docker available.
This is most useful if you're on OS X and do not want
to use boot2docker.
Now uses 'docker cp' instead of tar piping to transfer files. This
currently must be done by copying the binaries off of the docker volume
and into a local filesystem (/tmp) before a docker cp is done. This
workaround will no longer be necessary after bug fix
moby/moby#8509 makes it into stable.
This was necessary because the tar | tar method was creating corrupted
archives on OS X even with the < /dev/null workaround.
8 participants
Fixes #1992
Right now when you
docker cpa path which is in a volume, the cpitself 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 cpa path that is in a volume itfollows 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" insteadof 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 beexpecting "foo", not the ID