Closed
Description
Description of problem:
When using COPY
in a Dockerfile
and using globs to copy files & folders, docker will (sometimes?) also copy files from subfolders to the destination folder.
$ docker version
Client:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 19:47:52 UTC 2015
OS/Arch: darwin/amd64
Server:
Version: 1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: 0d03096
Built: Tue Aug 11 17:17:40 UTC 2015
OS/Arch: linux/amd64
$ docker info
Containers: 26
Images: 152
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 204
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.0.9-boot2docker
Operating System: Boot2Docker 1.8.0 (TCL 6.3); master : 7f12e95 - Tue Aug 11 17:55:16 UTC 2015
CPUs: 4
Total Memory: 3.858 GiB
Name: dev
ID: 7EON:IEHP:Z5QW:KG4Z:PG5J:DV4W:77S4:MJPX:2C5P:Z5UY:O22A:SYNK
Debug mode (server): true
File Descriptors: 42
Goroutines: 95
System Time: 2015-08-26T17:17:34.772268259Z
EventsListeners: 1
Init SHA1:
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker
Username: jfchevrette
Registry: https://index.docker.io/v1/
Labels:
provider=vmwarefusion
$ uname -a
Darwin cerberus.local 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64
Environment details:
Local setup on OSX /w boot2docker built with docker-machine
How to Reproduce:
Context
$ tree
.
├── Dockerfile
└── files
├── dir
│ ├── dirfile1
│ ├── dirfile2
│ └── dirfile3
├── file1
├── file2
└── file3
Dockerfile
FROM busybox
RUN mkdir /test
COPY files/* /test/
Actual Results
$ docker run -it copybug ls -1 /test/
dirfile1
dirfile2
dirfile3
file1
file2
file3
Expected Results
The resulting image should have the same directory structure from the context
Activity
jfchevrette commentedon Aug 26, 2015
Updated original message with output from
docker info
anduname -a
and reformatted it to be according to the issue reporting template.jrabbit commentedon Sep 1, 2015
I've had this on 1.6.2 and 1.8
https://gist.github.com/jrabbit/e4f864ca1664ec0dd288 second level directories are treated as first level ones should be for some reason?
for those googling: if you're having issues with COPY * /src try COPY / /src
duglin commentedon Sep 1, 2015
@jfchevrette I think I know why this is happening.
You have
COPY files/* /test/
which expands toCOPY files/dir files/file1 files/file2 files/file /test/
. If you split this up into individual COPY commands (e.g.COPY files/dir /test/
) you'll see that (for better or worse) COPY will copy the contents of each arg dir into the destination dir. Not the arg dir itself, but the contents. If you added a 3rd level of dirs I bet those will stick around.I'm not thrilled with that fact that COPY doesn't preserve the top-level dir but its been that way for a while now.
You can try to make this less painful by copying one level higher in the src tree, if possible.
jfchevrette commentedon Sep 1, 2015
I'm pretty confident that @duglin in right and it could be very risky to change that behavior. many dockerfiles may break or simply copy inuntended stuff.
However I'd argue that for the long run it would be better if COPY was following the way tools such as cp or rsync handle globs & trailing slashes on folders. It's definitely not expected for COPY to copy files from a subfolder matching dir/* into the destination IMO
duglin commentedon Sep 1, 2015
@jfchevrette yep - first chance we get we should "fix" this.
Closing it for now...
tugberkugurlu commentedon Feb 27, 2016
@duglin so, closing means it will not get fixed?
duglin commentedon Feb 27, 2016
@tugberkugurlu yup, at least for now. There's work underway to redo the entire build infrastructure and when we do that is when we can make COPY (or its new equivalent) act the way it should.
tugberkugurlu commentedon Feb 27, 2016
@duglin thanks. Is it possible to keep this issue open and update the status here? Or is there any other issue for this that I can subscribe to?
duglin commentedon Feb 27, 2016
@tugberkugurlu I thought we had an issue for "client-side builder support" but I can't seem to find it. So all we may have is what the ROADMAP ( https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax ) says.
As for keeping the issue open, I don't think we can do that. The general rule that Docker has been following is to close any issue that isn't actionable right away. Issues for future work are typically closed and then reopened once the state of things change such that some action (PR) can be taken for the issue.
deric commentedon Nov 5, 2016
@duglin This is very serious issue, you shouldn't just close it because the problem was introduced in 0.1 release. It would be more appropriate to target this for 2.0 release (milestones are on github too).
I guess most people use:
and blacklist all other folders in
.gitignore
or have single level directory structure and useCOPY
which actually hasmv
semantics:It's quite hard for me to imagine that someone would actually use
COPY
for flattening directory structure. The other workaround for this is usingtar -cf .. & ADD tarfile.tar.gz
. Changing at least this would be really helpful. The other thing is respecting slashes in directory namesCOPY src /src
vsCOPY src/ /src
(which are currently completely ignored).tjwebb commentedon Jan 14, 2017
@duglin This is a ridiculous and infuriating issue and should not be closed. The
COPY
command behaves specifically in disagreement with the documented usage and examples.thaJeztah commentedon Jan 14, 2017
@tjwebb there's still an open issue #29211. This can only be looked into if there's a way to fix this that's fully backward compatible. We're open to suggestions if you have a proposal how this could be implemented (if you do, feel free to write this up, and open a proposal, linking to this issue). Note that there's already a difference between (for example), OS X, and Linux in the way
cp
is handled;OS X:
On Ubuntu (/bin/sh)
86 remaining items