Error building with docker #88
Assignees
Comments
|
Found a workaround. Seems like Changing func copyFromDockerContainer(
id: String,
from containerPath: FilePath,
to localPath: FilePath,
failIfNotExists: Bool = true
) async throws {
if !failIfNotExists {
guard try await doesPathExist(containerPath, inContainer: id)
else { return }
}
try await Shell.run(
"\(Self.dockerCommand) cp \(id):\(containerPath) - | tar xC $(dirname \(localPath))",
shouldLogCommands: self.isVerbose
)
} |
euanh
added a commit
to euanh/swift-sdk-generator
that referenced
this issue
Mar 19, 2024
`docker cp` tries to avoid creating simlinks which would break out of the directory it is creating. In apple#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 apple#88
euanh
added a commit
that referenced
this issue
Mar 19, 2024
`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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am trying to build a SDK that includes
libvips:I created an image:
Then, using the SDK generator:
Fails with:
The text was updated successfully, but these errors were encountered: