Open
Description
Description
Dockerfile COPY[dir1/* destdir] copies dir1/dir2/*
Steps to reproduce the issue:
- mkdir test; cd test
- mkdir -p conf/etc/apt/apt.conf.d/
- touch conf/etc/apt/apt.conf.d/some_file
- touch Dockerfile with content
FROM ubuntu:16.04
MAINTAINER Andrii Zhuk <https://github.com/ashlander>
# what dirs and files are inside the project
ENV root_apt_conf conf/etc/apt/apt.conf.d
ENV root_apt_conf_file conf/etc/apt/apt.conf.d/some_file
ENV test_conf /var/tmp/test/conf
RUN mkdir -p ${test_conf}
COPY ["conf/*" ,"${test_conf}/"] # Can't be used to copy conf directory content... bug ?
# I know this is how copy should be made, but i was expecting these two will be similar, and not "go even deeper"
#COPY ["conf" ,"${test_conf}/"]
RUN ls -la ${test_conf} # present
RUN ls -la ${test_conf}/apt # present, where is etc gone ?!
RUN ls -la ${test_conf}/apt/apt.conf.d # present ?!
RUN ls -la ${test_conf}/etc # missing
RUN ls -la ${test_conf}/etc/apt # missing
RUN ls -la ${test_conf}/etc/apt/apt.conf.d # missing
Describe the results you received:
I have items copied like /var/tmp/test/conf/apt/apt.conf.d/some_file
Describe the results you expected:
I expect items copied like /var/tmp/test/conf/etc/apt/apt.conf.d/some_file
Output of docker version:
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 21:39:14 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 21:39:14 2016
OS/Arch: linux/amd64
Output of docker info:
Containers: 5
Running: 1
Paused: 0
Stopped: 4
Images: 188
Server Version: 1.12.3
Storage Driver: aufs
Root Dir: /mount/store/docker/aufs
Backing Filesystem: extfs
Dirs: 123
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: host overlay null bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.7 GiB
Name: juk
ID: MZCE:5V4P:6J5C:K33F:V4U4:GU33:7UQB:N3VX:T3XO:3HK3:EWYL:ZCFS
Docker Root Dir: /mount/store/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Insecure Registries:
127.0.0.0/8
Additional environment details (AWS, VirtualBox, physical, etc.):
physical
Activity
thaJeztah commentedon Dec 8, 2016
ping @duglin is this the same / related to #15858 ?
ashlander commentedon Dec 9, 2016
@thaJeztah thanks for pointing me to the same thing, i believe you are right about the case. Unfortunately i was looking inside open issues for duplicates.
However this is explained but still confusing, i would vote for adding some warning example inside documentation, at least.
Thanks
duglin commentedon Dec 28, 2016
@ashlander If you look at:https://docs.docker.com/engine/reference/builder/#/copy you'll see a "Note" that says:
Note: The directory itself is not copied, just its contents.. Do you think more is needed?ashlander commentedon Dec 28, 2016
@duglin while i was trying to understand the reason, this note was read dozen of times, but that was not describing why destination directory contents and source directory contents do not match. In short, for such a dummies as myself, hell yea... possibly, just adding link to #15858 in documentation somewhere near.
Thanks
zentby commentedon May 3, 2018
Looks all discussions went to #15858
Any update here?
amoseev commentedon Sep 23, 2018
What about alternative syntax (command name or parameter)?
[-]Dockerfile COPY[dir1/* destdir] copies dir1/dir2/* [/-][+]Dockerfile COPY [dir1/* destdir] copies dir1/dir2/* [/+]Fryuni commentedon Apr 8, 2020
Any progress on this in the last few years? This requires so much hacks to work around
limitedAtonement commentedon Nov 5, 2020
As far as I can tell, there is no acceptable workaround for this problem. I understand that backwards compatibility is a requirement for any fix. I think the best backward-compatible fix for this problem would be to introduce a new Dockerfile command,
cp. This has the added advantage that newcomers who don't know about "copy" (because they're accustomed to standard POSIX tools) won't have as many wasted hours and nightmares as the graybeards have had. If a new command is undesirable for some reason, perhaps adding a flagcopy --not-broken /dir1/ /is acceptable?code4happylife commentedon Aug 16, 2022
Lose a layer of directory after using COPY command in Dockerfile...
thaJeztah commentedon Aug 16, 2022
Work is in progress in BuildKit to introduce a
--parentsoption onADDandCOPY, which may help with this (at least for some cases); seeparentsoption to dockerfile COPY command #35639