Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: buildx breaks symlinks when copying them #373

Open
claudiubelu opened this issue Aug 31, 2020 · 2 comments · May be fixed by moby/buildkit#2239
Open

Windows: buildx breaks symlinks when copying them #373

claudiubelu opened this issue Aug 31, 2020 · 2 comments · May be fixed by moby/buildkit#2239

Comments

@claudiubelu
Copy link

docker buildx breaks Windows symlinks when copying them over from another Windows image by prepending Files\ to their target. If the original symlink targets are absolute paths, they become unusable.

For example, let's have this Dockerfile and build a Windows image on a Windows node:

FROM mcr.microsoft.com/windows/nanoserver:1809

ADD https://github.com/kubernetes-sigs/windows-testing/raw/master/images/busybox/busybox.exe /bin/busybox.exe
USER ContainerAdministrator
RUN cd C:\bin && FOR /f "tokens=*" %i IN ('.\busybox --list') DO mklink .\%i.exe C:\bin\busybox.exe

The Dockerfile will basically create a C:\bin folder and create symlinks to C:\bin\busybox.exe. We can check that the symlinks are correct:

docker run claudiubelu/sample:1.29.0 cmd /S /C "dir C:\\bin"
 Volume in drive C has no label.
 Volume Serial Number is AEAD-02B2

 Directory of C:\bin

08/31/2020  04:34 PM    <DIR>          .
08/31/2020  04:34 PM    <DIR>          ..
08/31/2020  04:34 PM    <SYMLINK>      ar.exe [C:\bin\busybox.exe]
08/31/2020  04:34 PM    <SYMLINK>      arch.exe [C:\bin\busybox.exe]
...

Then, we're copying C:\bin to another image with docker buildx on a Linux node with the following Dockerfile:

ARG BASEIMAGE
ARG REGISTRY

FROM $REGISTRY/sample:1.29.0 as helper
FROM $BASEIMAGE

COPY --from=helper /bin /bin

# NOTE(claudiub): docker buildx sets the PATH env variable to a Linux-like PATH, which is not desirable.
ENV PATH="C:\bin;C:\Windows\System32;C:\Windows;"

ENTRYPOINT ["cmd.exe", "/s", "/c"]

The command is: docker buildx build --no-cache --pull --output=type=registry --platform windows/amd64 --build-arg BASEIMAGE=mcr.microsoft.com/windows/nanoserver:1809 --build-arg REGISTRY=claudiubelu -t claudiubelu/symlink-sample:1.29 .

Checking the symlinks in the newly image, we notice that Files\ is prepended to their targets:

docker run claudiubelu/symlink-sample:1.29 dir C:\bin
 Volume in drive C has no label.
 Volume Serial Number is AEAD-02B2

 Directory of C:\bin

08/31/2020  04:44 PM    <DIR>          .
08/31/2020  04:44 PM    <DIR>          ..
08/31/2020  04:34 PM    <SYMLINK>      ar.exe [Files\C:\bin\busybox.exe]
08/31/2020  04:34 PM    <SYMLINK>      arch.exe [Files\C:\bin\busybox.exe]
...

One workaround for this is to make the original symlinks with relative paths (to busybox.exe).Files\ will still be prepended to the target paths, but the busybox binary could be copied to C:\bin\Files\busybox.exe, which means that they will point to something that exists:

ARG BASEIMAGE
ARG REGISTRY

FROM $REGISTRY/sample:1.29.0 as helper
FROM $BASEIMAGE

COPY --from=helper /bin /bin

# NOTE(claudiub): Unfortunately, docker buildx has some issues copying over Windows symlinks.
# "Files/" is always prepended to the symlink target. The symlinks themselves are relative paths,
# so, in order to make use of them, we can simply add a busybox binary to C:\bin\Files\busybox.exe.
COPY --from=helper /bin/busybox.exe /bin/Files/

# NOTE(claudiub): docker buildx sets the PATH env variable to a Linux-like PATH, which is not desirable.
ENV PATH="C:\bin;C:\Windows\System32;C:\Windows;"

ENTRYPOINT ["cmd.exe", "/s", "/c"]

Docker buildx version: github.com/docker/buildx v0.4.1-25-ge24e04b e24e04b

@tonistiigi
Copy link
Member

Can you post an image that you use as helper so we can use it to test and look at what is inside it?

@claudiubelu
Copy link
Author

Can you post an image that you use as helper so we can use it to test and look at what is inside it?

The helper image you mentioned is built using the 1st Dockerfile mentioned in this issue. I currently have it published as claudiubelu/sample:1.29.0

@claudiubelu claudiubelu linked a pull request Jul 10, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants