Ignore destination symbolic links during build acceleration

[giovanni-bozzano]

Fixes #9548

When using symbolic links for build output, build acceleration causes exceptions because it attempts to copy the source file over a symbolic link that points back to the source file itself. Therefore, if the destination is a symbolic link, we ignore it.

Microsoft Reviewers: Open in CodeFlow

[adamint]

@drewnoakes

[drewnoakes]

Thanks @giovanni-bozzano! This looks great. I will need a bit of time to give this a proper review. One initial though it that perhaps we move this behind the file system abstraction so it can be more easily mocked. Another thought it whether we should disable build acceleration for a project altogether when targets are symbolic links. The goal is parity with MSBuild. Do you know how MSBuild handles this case?

[giovanni-bozzano]

Thanks @giovanni-bozzano! This looks great. I will need a bit of time to give this a proper review. One initial though it that perhaps we move this behind the file system abstraction so it can be more easily mocked. Another thought it whether we should disable build acceleration for a project altogether when targets are symbolic links. The goal is parity with MSBuild. Do you know how MSBuild handles this case?

MSBuild optionally creates (and overwrites) symbolic links in the Copy task using native calls:
https://github.com/dotnet/msbuild/blob/53a2d6ba9edc932e724dc80a5a56eeb9943863cf/src/Tasks/Copy.cs#L352

In the build target, UseSymboliclinksIfPossible is controlled by the properties listed in #9747, depending on the artifacts.
For this reason, build acceleration can still be useful if symbolic links are enabled for only a subset of build artifacts.

I suppose the desired outcome would be to recreate symbolic links like MSBuild, in order to also update their timestamps, or at least checking if the link target is the same as the source file.
But these actions require using native calls, so for now I didn't include them in the pull request.