summaryrefslogtreecommitdiff
path: root/bin/spack_pwsh.ps1
diff options
context:
space:
mode:
authorJohn W. Parent <45471568+johnwparent@users.noreply.github.com>2023-03-17 13:19:32 -0400
committerGitHub <noreply@github.com>2023-03-17 10:19:32 -0700
commit8195f27a661846311eae8412f8b8b3f0f0c2d368 (patch)
tree205c0c3f6fe8c15b19a3a078034c6b57ae001503 /bin/spack_pwsh.ps1
parenta60fa7ff7daba493fd8e5482be99d4cbeba4fdef (diff)
downloadspack-8195f27a661846311eae8412f8b8b3f0f0c2d368.tar.gz
spack-8195f27a661846311eae8412f8b8b3f0f0c2d368.tar.bz2
spack-8195f27a661846311eae8412f8b8b3f0f0c2d368.tar.xz
spack-8195f27a661846311eae8412f8b8b3f0f0c2d368.zip
Windows: properly handle symlink failures (#36003)
In the Windows filesystem logic for creating a symlink, we intend to fall back to a copy when the symlink cannot be created (for some configuration settings on Windows it is not possible for the user to create a symlink). It turns out we were overly-broad in which exceptions lead to this fallback, and the subsequent copy would also fail: at least one case where this occurred is when we attempted to create a symlink that already existed. The updated logic expressly avoids falling back to a copy when the file/symlink already exists.
Diffstat (limited to 'bin/spack_pwsh.ps1')
0 files changed, 0 insertions, 0 deletions