System.IO.FileInfo and Relative Paths

Question

I was wondering if someone could help me understand why does System.IO.FileInfo behaves differently on Windows than on Linux when handling relative paths.

Example

• On Linux

PS /home/user/Documents> ([System.IO.FileInfo]'./test.txt').FullName
/home/user/Documents/test.txt

• On Windows

PS C:\Users\User\Documents> ([System.IO.FileInfo]'.\test.txt').FullName
C:\Users\User\test.txt

---

EDIT

To clarify on the above, there is no difference on how System.IO.FileInfo handles relative paths on Windows or Linux. The issue is related to [System.IO.Directory]::GetCurrentDirectory() not being updated by Push-Location or Set-Location.

A simple example:

PS /home/user> [System.IO.Directory]::GetCurrentDirectory()
/home/user
PS /home/user> cd ./Documents/
PS /home/user/Documents> [System.IO.Directory]::GetCurrentDirectory()
/home/user

---

And assuming this is a expected behavior, what would be an optimal way to approach our param(...) blocks on scripts and functions to accept both cases (absolute and relative). I used to type constraint the path parameter to System.IO.FileInfo but now I can see it is clearly wrong.

This is what I came across, but I'm wondering if there is a better way.
I believe Split-Path -IsAbsolute will also bring problems if working with Network Paths, please correct me if I'm wrong.

param(
    [ValidateScript({ 
        if(Test-Path $_ -PathType Leaf) {
            return $true
        }
        throw 'Invalid File Path'
    })]
    [string] $Path
)

if(-not (Split-Path $Path -IsAbsolute)) {
    [string] $Path = Resolve-Path $Path
}

Answer 1

Feels a bit duplicate, but since you asked..

I'm sorry I don't know about Linux, but in Windows:

You can add a test first to see if the path is relative and if so, convert it to absolute like:

$Path = '.\test.txt'
if (![System.IO.Path]::IsPathRooted($Path) -or $Path -match '^\\[^\\]+') {
    $Path =  [System.IO.Path]::GetFullPath([System.IO.Path]::Combine($pwd, $Path))
}

^{I added $Path -match '^\\[^\\]+' to also convert relative paths starting with a backslash like \ReadWays.ps1 meaning the path starts at the root directory. UNC paths that start with two backslashes are regarded as absolute.}

---

Apparently (I really have no idea why..) the above does not work on Linux, because there, when using a UNC path, the part ![System.IO.Path]::IsPathRooted('\\server\folder') yields True.

It seems then you need to check the OS first and do the check differently on Linux.

$Path = '\\server\share'

if ($IsWindows) {  # $IsWindows exists in version 7.x. Older versions do `$env:OS -match 'Windows'`
    if (![System.IO.Path]::IsPathRooted($Path) -or $Path -match '^\\[^\\]+') {
        $Path =  [System.IO.Path]::GetFullPath([System.IO.Path]::Combine($pwd, $Path))
    }
}
else {
    if ($Path -notlike '\\*\*') {  # exclude UNC paths as they are not relative
        if (![System.IO.Path]::IsPathRooted($Path) -or $Path -match '^\\[^\\]+') {
            $Path =  [System.IO.Path]::GetFullPath([System.IO.Path]::Combine($pwd, $Path))
        }
    }
}

Answer 2

The easiest alternative would be to use Convert-Path to:

• Handle UNC, Relative, Absolute and Rooted Paths.
• Be compatible with Windows and Linux
• Be efficient

Another neat option if we are using [cmdletbinding()] is to use $PSCmdlet.GetUnresolvedProviderPathFromPSPath(..) method:

function Test-ResolvePath {
    [cmdletbinding()]
    param($path)
    $PSCmdlet.GetUnresolvedProviderPathFromPSPath($path)
}

Test-ResolvePath \\server01\test         # => \\server01\test
Test-ResolvePath C:\Users\user\Documents # => C:\Users\user\Documents
Test-ResolvePath C:Documents             # => C:\Documents
(Test-ResolvePath .) -eq $PWD.Path       # => True
(Test-ResolvePath ~) -eq $HOME           # => True

---

If we're looking to emulate the behavior of most Microsoft.PowerShell.Management cmdlets, having a -LiteralPath and -Path the code would be a bit more complex and the APIs being called are also different, PathIntrinsics.GetUnresolvedProviderPathFromPSPath method for literal path validation and PSCmdlet.GetResolvedProviderPathFromPSPath method for wildcard path validation. Both methods ensure that the target exists.

function Test-ResolvePath {
    [cmdletbinding(DefaultParameterSetName = 'Path')]
    param(
        [Parameter(ParameterSetName = 'LiteralPath', Mandatory, Position = 0)]
        [string] $LiteralPath,

        [Parameter(ParameterSetName = 'Path', Mandatory, Position = 0)]
        [SupportsWildcards()]
        [string] $Path
    )

    $provider = $null

    try {
        if ($PSCmdlet.ParameterSetName -eq 'LiteralPath') {
            $resolvedPath = $PSCmdlet.SessionState.Path.GetUnresolvedProviderPathFromPSPath(
                $LiteralPath,
                [ref] $provider,
                [ref] $null)
        }
        else {
            $resolvedPath = $PSCmdlet.GetResolvedProviderPathFromPSPath(
                $Path,
                [ref] $provider)
        }

        foreach ($path in $resolvedPath) {
            [pscustomobject]@{
                Path             = $path
                Provider         = $provider
                IsFileSystemPath = $provider.ImplementingType -eq [Microsoft.PowerShell.Commands.FileSystemProvider]
            }
        }
    }
    catch {
        $PSCmdlet.WriteError($_)
    }
}

Test-ResolvePath $pwd\*
Test-ResolvePath HKLM:
Test-ResolvePath -LiteralPath Cert:
Test-ResolvePath doesnotexist

Answer 3

Another option:

As you wanted the result of a cast to [System.IO.FileInfo], you can instead use Get-Item, which will also return a [System.IO.FileInfo] object, but with resolved relative paths as expected. It will also incorporate some error detection (invalid characters or non-existent path etc.).

Example:

PS C:\Users\User\Documents> (Get-Item -LiteralPath '.\test.txt').FullName
C:\Users\User\Documents\test.txt