Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
generator: Handle symlinks when copying from a container (#90)
`docker cp` tries to avoid creating simlinks which would break out of the directory it is creating. In #88, when copying `/usr/lib/x86_64-linux-gnu` from a running container, a symlink pointing back 4 layers is rejected: invalid symlink: <dest>/usr/lib/x86_64-linux-gnu/hdf5/serial/include" -> "../../../../include/hdf5/serial" The intended target of the symlink is in `<dest>/usr/include` which is outside the path being copied. The error message is generated here: https://github.com/moby/moby/blob/dd146571ea458082c499c647ba36580bb7277131/pkg/archive/archive.go#L753 Symlinks which point inside the directory tree being copied do not cause errors: <dest>/usr/lib/x86_64-linux-gnu/libxcb-render.so.0 -> libxcb-render.so.0.0.0 The "hdf5 include" error does not occur if we copy the whole of the `/usr` directory from the container, making the symlink no longer break out of the copied directory: % docker cp <container>:/usr <dest> Successfully copied 3.24GB to <dest> This commit avoids the error by asking `docker cp' to print a 'tar' stream to standard output and piping it to a local `tar` process. The local `tar` does not complain about creating potential dangling symlinks. The performance of piping to 'tar' should be similar to using "normal" `docker cp` because `dockerd` always sends a `tar` stream to the `docker` CLI. In the normal case, `docker cp` unarchives the `tar` stream, using the library which checks for symlinks which break out of the tree. In the "tar stream" case, `docker cp` just prints the stream to standard output. Co-authored-by: @t089 Fixes #88
- Loading branch information