Workload install copying across mounts error

The files on disk workload install needs to copy files into both the user’s home (advertising manifests) and the dotnet directory (packs, installed manifests). This can cause problems with those are under different mounts, for example, the default user home on linux is /home/... and you could potentially install dotnet to /mnt/.... This is problematic because install uses one temp directory and has to be able to copy from that temp directory into both the home and dotnet directories. When the mounts for these locations conflict we run into a Invalid cross-device link. error (https://github.com/dotnet/runtime/issues/31149).

Repro: Workload install using WSL

Error output:

/mnt/c/code/tmp2$ ./dotnet workload install microsoft-net-sdk-blazorwebassembly-aot Skip NuGet package signing validation. NuGet signing validation is not available on Linux or macOS https://aka.ms/workloadskippackagevalidation . Updated advertising manifest microsoft.net.sdk.android. Updated advertising manifest microsoft.net.sdk.ios. Updated advertising manifest microsoft.net.sdk.maccatalyst. Updated advertising manifest microsoft.net.sdk.macos. Failed to update the advertising manifest microsoft.net.sdk.maui: microsoft.net.sdk.maui.manifest-6.0.100 is not found in NuGet feeds https://api.nuget.org/v3/index.json"… Updated advertising manifest microsoft.net.sdk.tvos. Updated advertising manifest microsoft.net.workload.mono.toolchain. Installing workload manifest microsoft.net.sdk.android version 30.0.100-preview.5.28. Workload installation failed, rolling back installed packs… Installing workload manifest microsoft.net.sdk.android version 11.0.200-ci.main.256. Installation roll back failed: Failed to install manifest microsoft.net.sdk.android version 11.0.200-ci.main.256: The transaction has aborted… Workload installation failed: Failed to install manifest microsoft.net.sdk.android version 30.0.100-preview.5.28: Invalid cross-device link.

[jonathanpeppers]

Saw this on Windows, might be related: https://github.com/dotnet/sdk/issues/18516

[sfoslund]

Yes, I think this was all a result of https://github.com/dotnet/sdk/pull/17860, where we changed to using the machine’s default temp location, which on linux is often on a different mount from the dotnet install location. I’ll get a PR out to fix this today but in the meantime it can be worked around by using the --temp-dir option and specifying a temp location within the same mount as the dotnet installation.