Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

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

Copy link
Copy link
@mklement0

Description

@mklement0
Issue body actions

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
Reactions are currently unavailable

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-FileSystem-Providerspecific to the FileSystem providerspecific to the FileSystem providerIssue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Cmdlets-Managementcmdlets in the Microsoft.PowerShell.Management modulecmdlets in the Microsoft.PowerShell.Management moduleWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.