Why might uv in a Windows container make a .venv with a Lib that cannot be copied?

[doctorpangloss]

FROM mcr.microsoft.com/windows/server:10.0.20348.1970 AS build
USER ContainerAdministrator

ARG PIP_DISABLE_PIP_VERSION_CHECK=1
ARG PIP_NO_CACHE_DIR=1

RUN powershell -NoProfile -ExecutionPolicy Bypass -Command "[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))"
RUN choco install -y --no-progress python --version=3.11.9
RUN choco install -y --no-progress git cmake

WORKDIR C:/

RUN powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
RUN uv venv --seed
RUN C:/.venv/scripts/activate.bat

# Copy from the cache instead of linking since it's a mounted volume
ENV UV_LINK_MODE=copy
...

FROM mcr.microsoft.com/windows/server:10.0.20348.1970 AS final
USER ContainerAdministrator
COPY --link --from=build C:/Python311 C:/Python311
COPY --link --from=build C:/.venv C:/.venv

leads to:

Step 47/57 : COPY --link --from=build C:/.venv C:/.venv
COPY failed: open \\?\Volume{187fc7e0-9270-488a-9d90-06f9ad730fd4}\.venv\Lib: Access is denied.

Does UV_LINK_MODE interact with uv venv ?

[zanieb]

Are you looking for the --relocatable flag? I believe the link mode only affects package installation but handling of the Python interpreter in a virtual environment.