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

New-Item Type SymbolicLink on Unix-like platforms unexpectedly converts relative target paths to absolute one #15233

Closed
mklement0 opened this issue Apr 14, 2021 · 4 comments
Labels
Area-FileSystem-Provider specific to the FileSystem provider Issue-Bug Issue has been identified as a bug in the product Resolution-No Activity Issue has had no activity for 6 months or more WG-Cmdlets-Management cmdlets in the Microsoft.PowerShell.Management module WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

Comments

@mklement0
Copy link
Contributor

PR #12797 tried to implement support for relative target paths for symbolic links (symlinks).

  • On Windows, this now works properly.

  • On Unix-like platforms, a relative input path is still unexpectedly converted to a full path and stored as such in the symlink.

Steps to reproduce

Note: Run on macOS and/or Linux (the test succeeds on Windows).

Push-Location -ea Stop ($tmpDir = (New-Item -Type Directory -Force (Join-Path Temp:/ $PID)).FullName)

# Create a file to serve as the symlink target.
$null = New-Item -Force file

# Determine the native file-system path separator, as well as the one 
# *not* native to the platform.
$sep = [IO.Path]::DirectorySeparatorChar
$otherSep = $sep -eq '/' ? '\' : '/'

# To also test path-separator normalization, we use the non-native separator.
$null = New-Item -Force -Type SymbolicLink fileL -Target ".${otherSep}file"

# The symlink's target should be a relative path that uses the platform-appropriate path separator.
(Get-Item fileL).Target | Should -Be ".${sep}file"

# Clean up.
Pop-Location; Remove-Item $tmpDir -Recurse

Expected behavior

The test should succeed.

Actual behavior

The test fails, because the relative input path is unexpectedly first resolved to a full path before the symlink is defined:

InvalidResult: Expected strings to be the same, but they were different. 
Expected length: 6 Actual length:   14 Strings differ at index 0. 
Expected: './file' But was: '/tmp/2802/file'

Environment data

PowerShell Core 7.2.0-preview.4
@mklement0 mklement0 added the Needs-Triage The issue is new and needs to be triaged by a work group. label Apr 14, 2021
@iSazonov iSazonov added WG-Cmdlets-Core cmdlets in the Microsoft.PowerShell.Core module WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc. Issue-Bug Issue has been identified as a bug in the product labels Apr 15, 2021
@iSazonov iSazonov added this to the 7.2-Consider milestone Apr 15, 2021
@daxian-dbw daxian-dbw removed the Needs-Triage The issue is new and needs to be triaged by a work group. label Jun 9, 2021
@iSazonov iSazonov added Area-FileSystem-Provider specific to the FileSystem provider WG-Cmdlets-Management cmdlets in the Microsoft.PowerShell.Management module and removed WG-Cmdlets-Core cmdlets in the Microsoft.PowerShell.Core module labels Dec 3, 2021
Copy link
Contributor

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

2 similar comments
Copy link
Contributor

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

Copy link
Contributor

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

@microsoft-github-policy-service microsoft-github-policy-service bot added Resolution-No Activity Issue has had no activity for 6 months or more labels Nov 16, 2023
Copy link
Contributor

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-FileSystem-Provider specific to the FileSystem provider Issue-Bug Issue has been identified as a bug in the product Resolution-No Activity Issue has had no activity for 6 months or more WG-Cmdlets-Management cmdlets in the Microsoft.PowerShell.Management module WG-Engine-Providers built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.
Projects
None yet
Development

No branches or pull requests

3 participants