There are many cases where it would be helpful to allow referenced file(s) (outside of the current build path) to be used but I'll add just one for now to make the issue a bit more concrete...
When having to build many docker images which rely on common configuration files (e.g. repo files, system config, etc.), it is not optimal to have to copy these files into the Dockerfile directories that depend on them. If a change is needed to one or all of these files, one must ensure that all the directories are appropriately updated. If file links (symlinks) were allowed, this would enable one to maintain & update a single file that can be used across all Dockerfiles
eg. Directory structure:
.../DockerImages/
configfile
image1/
Dockerfile
configfile -> ../configfile
image2/
Dockerfile
configfile -> ../configfile
e.g. Dockerfile
...
COPY configfile /etc/program/
...
e.g. Docker image1 build$ cd DockerImages/image1$ docker build -t images:image1 ./
Proposal:
I am not proposing that we persist the links, rather copy/dereference the linked file into the build-path (on the client side) prior to sending it off to the server to create/build the image. My understanding is that on the client side, the Dockerfile directory is tar'd up prior to sending to the server. You could use the --dereference (-h) flag to achieve this behavior.
docker version
Client:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:25:01 UTC 2015
OS/Arch: linux/amd64
Current Docker version:
Server:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:25:01 UTC 2015
OS/Arch: linux/amd64
docker info
Containers: 0
Images: 6
Server Version: 1.9.1
Storage Driver: devicemapper
Pool Name: docker-253:0-201129991-pool
Pool Blocksize: 65.54 kB
Base Device Size: 107.4 GB
Backing Filesystem: xfs
Data file: /dev/direct-lvm/data
Metadata file: /dev/direct-lvm/metadata
Data Space Used: 12.56 GB
Data Space Total: 15.2 TB
Data Space Available: 15.19 TB
Metadata Space Used: 79.18 MB
Metadata Space Total: 17.05 GB
Metadata Space Available: 16.97 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Library Version: 1.02.107-RHEL7 (2015-10-14)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.14.1.el7.x86_64
Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
CPUs: 32
Total Memory: 188.6 GiB
Name: deployer-01.cloud.svl.ibm.com
ID: OEPB:5NYE:KJDO:QGSZ:2BCD:5LXZ:KH22:NLOY:2JGK:2XUR:NHVF:O4YV
Debug mode (server): true
File Descriptors: 18
Goroutines: 26
System Time: 2016-01-08T11:51:50.047754961-08:00
EventsListeners: 0
Init SHA1: ac8f1bfea8577235f1e9c2dfaace54207d64ee49
Init Path: /usr/libexec/docker/dockerinit
Docker Root Dir: /var/lib/docker
phemmer
commented
8 years ago 
stmuraka
Use Case:
There are many cases where it would be helpful to allow referenced file(s) (outside of the current build path) to be used but I'll add just one for now to make the issue a bit more concrete...
When having to build many docker images which rely on common configuration files (e.g. repo files, system config, etc.), it is not optimal to have to copy these files into the Dockerfile directories that depend on them. If a change is needed to one or all of these files, one must ensure that all the directories are appropriately updated. If file links (symlinks) were allowed, this would enable one to maintain & update a single file that can be used across all Dockerfiles
eg. Directory structure:
e.g. Dockerfile ... COPY configfile /etc/program/ ...
e.g. Docker image1 build
$ cd DockerImages/image1$ docker build -t images:image1 ./Proposal:
I am not proposing that we persist the links, rather copy/dereference the linked file into the build-path (on the client side) prior to sending it off to the server to create/build the image. My understanding is that on the client side, the Dockerfile directory is tar'd up prior to sending to the server. You could use the
--dereference(-h) flag to achieve this behavior.docker version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:25:01 UTC 2015 OS/Arch: linux/amd64
Current Docker version:
Server: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:25:01 UTC 2015 OS/Arch: linux/amd64
docker info Containers: 0 Images: 6 Server Version: 1.9.1 Storage Driver: devicemapper Pool Name: docker-253:0-201129991-pool Pool Blocksize: 65.54 kB Base Device Size: 107.4 GB Backing Filesystem: xfs Data file: /dev/direct-lvm/data Metadata file: /dev/direct-lvm/metadata Data Space Used: 12.56 GB Data Space Total: 15.2 TB Data Space Available: 15.19 TB Metadata Space Used: 79.18 MB Metadata Space Total: 17.05 GB Metadata Space Available: 16.97 GB Udev Sync Supported: true Deferred Removal Enabled: false Deferred Deletion Enabled: false Deferred Deleted Device Count: 0 Library Version: 1.02.107-RHEL7 (2015-10-14) Execution Driver: native-0.2 Logging Driver: json-file Kernel Version: 3.10.0-229.14.1.el7.x86_64 Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo) CPUs: 32 Total Memory: 188.6 GiB Name: deployer-01.cloud.svl.ibm.com ID: OEPB:5NYE:KJDO:QGSZ:2BCD:5LXZ:KH22:NLOY:2JGK:2XUR:NHVF:O4YV Debug mode (server): true File Descriptors: 18 Goroutines: 26 System Time: 2016-01-08T11:51:50.047754961-08:00 EventsListeners: 0 Init SHA1: ac8f1bfea8577235f1e9c2dfaace54207d64ee49 Init Path: /usr/libexec/docker/dockerinit Docker Root Dir: /var/lib/docker