My Docker image includes some files, which are symlinks pointing outside of docker folder, e.g.
$ ls -l include/
total 0
lrwxrwxrwx 1 dmitry dmitry 29 Mar 30 17:25 python3.5m -> /usr/local/include/python3.5m
Native docker client handles this correctly. Java File.getCanonicalFile() follows symlinks, so TAR archive sent to Docker daemon contains usr/local/include/python3.5m/** instead of expected include/python3.5m/**, and as a result I get confusing errors about non-existent files.
I guess replacing FilePathUtil.relativize(File, File) with the following code would work, but please check if this behavior does not break other usages.
If you just use COPY for a symlink pointing outside of current build context, it will give an error lstat link: no such file or directory
If you copy relative symlink to a file inside current build context, you will get two copies of real file in the image
If you use COPY on a directory containing symlink, it will successfully build an image, where symlink is copied as a symlink, so it points to the same path in the container.
It seems that official documentation doesn't specify, what to do with symlinks, at all, so this might be a bug in docker cli or might be the intended behavior for some reason.
Regardless of the above, I believe that implementation should not put link pointing to /some/absolute/path into some/absolute/path in TAR archive sent to docker daemon.
I have another scenario with COPY a directory with symlinks inside. As @dvbobrov pointed, docker cli copies it just as symlinks. but using java-docker there's no file at all.
The normal behavior is to get a symlink.
Unfortunately, the @dvbobrov's proposal patch is not working:
[ERROR] symbol: variable LinkOption
[ERROR] location: class com.github.dockerjava.core.util.FilePathUtil
[ERROR] /usr/src/src/main/java/com/github/dockerjava/core/util/FilePathUtil.java:[26,39] cannot find symbol
I'm not a java developer but I can try for a fix if someone can give me some light :)
BTW, Sorry to respond on a 2 years old bug but it's still not solved.
The pull request is related to this bug because I fixed the units tests that now fails because symlink are not preserved. The only thing is the unit tests are testing CompressArchiveUtil.tar method which is not the method used when sending the docker build folder to docker daemon.
I will either add tests for CompressArchiveUtil.archiveTARFiles or rework both methods to remove the code duplication and then I will fix code to preserve symlinks.
Ok, the pull request #1211 fixed the unit tests as mentioned before and I also added the many tests to increase coverage to cover the tar created and passed to the docker daemon. I will work on fixing the issue now.
Activity
KostyaSha commented on Mar 30, 2016
Hi, could you investigate how docker cli works in this case?
dvbobrov commented on Mar 31, 2016
Oh, I got this wrong.
Docker cli behavior is the following:
It seems that official documentation doesn't specify, what to do with symlinks, at all, so this might be a bug in docker cli or might be the intended behavior for some reason.
Regardless of the above, I believe that implementation should not put link pointing to /some/absolute/path into some/absolute/path in TAR archive sent to docker daemon.
KostyaSha commented on Aug 15, 2016
@dvbobrov could you compare with docker cli behaviour and PR change with tests case?
joanayma commented on Mar 8, 2018
I have another scenario with COPY a directory with symlinks inside. As @dvbobrov pointed, docker cli copies it just as symlinks. but using java-docker there's no file at all.
The normal behavior is to get a symlink.
Unfortunately, the @dvbobrov's proposal patch is not working:
I'm not a java developer but I can try for a fix if someone can give me some light :)
BTW, Sorry to respond on a 2 years old bug but it's still not solved.
Fix CompressArchiveUtil unit tests
Fix CompressArchiveUtil unit tests
hugares commented on Jul 8, 2019
The pull request is related to this bug because I fixed the units tests that now fails because symlink are not preserved. The only thing is the unit tests are testing CompressArchiveUtil.tar method which is not the method used when sending the docker build folder to docker daemon.
I will either add tests for CompressArchiveUtil.archiveTARFiles or rework both methods to remove the code duplication and then I will fix code to preserve symlinks.
Fix CompressArchiveUtil unit tests
Fix CompressArchiveUtil unit tests
hugares commented on Jul 9, 2019
Ok, the pull request #1211 fixed the unit tests as mentioned before and I also added the many tests to increase coverage to cover the tar created and passed to the docker daemon. I will work on fixing the issue now.
Fix CompressArchiveUtil unit tests
Fix CompressArchiveUtil unit tests
Remove duplicated code to add a file to a tar
Remove duplicated code to add a file to a tar
Fix tar creation with symbolic link