Introduce a PowerShell-aware path-information class for convenient .NET interoperability

[iRon7]

Best practice answers and documentation often refer to .Net methods for file streaming where it concerns performance, e.g. Processing Large Files. But the .Net implementation differs from native PowerShell behavior were it concerns casting expectations and the current directory:

([io.fileinfo]'.\Test.txt').DirectoryName
C:\WINDOWS\system32
(Get-Item '.\Test.txt').DirectoryName
C:\Users\User\MyScripts

Btw. There is currently no accelerator or initiator for files:

[fileinfo]'.\Test.txt'

InvalidOperation: Unable to find type [fileinfo].

_{Note that [io.fileinfo]'.\Test.txt' strips the .\ from every member of the object which means if it is used for a parameter type, you can't discover anymore that the path was relative (using a condition as e.g. if ($FilePath.Name.StartsWith('.\')) {...), which means that you can only use a general string type for this instead.}

Using .net (streaming) methods generally require more coding therefore it often ends up in a separate function.
As a (spoiled) PowerShell engineer, I would expect to be able to do just this (wishful thinking):

Function Stream-File([FileInfo]$FilePath) {
    $Stream = [System.IO.StreamReader]$FilePath
    # ...
    $Stream.Dispose()
}

Stream-File .\Test.txt

This implies at least two things:

1. The (PowerShell) FileInfo constructor needs to accept a relative path that is than joined to the current path (Join-Path (Get-Location) '.\Test.txt') to prevent it expects the file in the C:\WINDOWS\system32 folder and to be accelerated to resolve the following error:

InvalidOperation: Unable to find type [FileInfo].

2. The [FileInfo] class should automatically cast to other file classes along with System.IO.StreamReader which current results in the following error:

Cannot convert the "C:\Users\User\MyScripts\Test.txt" value of type "System.IO.FileInfo" to type "System.IO.StreamReader".
InvalidOperation:

[jborean93]

This is really a known issue as the .NET methods use the process working directory whereas the PowerShell cmdlets rely on the Runspace location (see #3428 and linked issues in there). You can't really keep them in sync because there's only 1 process working dir but multiple Runspaces can exist inside a process. Maybe we just need to add some documentation (if there isn't already) on the best ways to write cmdlets to handle this properly. In my case I usually do the following to handle both -Path and -LiteralPath when calling .NET methods

Function Get-ItemLikeFunction {
    [CmdletBinding(DefaultParameterSetName='Path')]
    param (
        [Parameter(
            Mandatory = $true,
            Position = 0,
            ValueFromPipeline = $true,
            ValueFromPipelineByPropertyName = $true,
            ParameterSetName = 'Path'
        )]
        [SupportsWildcards()]
        [ValidateNotNullOrEmpty()]
        [String[]]
        $Path,

        [Parameter(
            Mandatory = $true,
            Position = 0,
            ValueFromPipelineByPropertyName = $true,
            ParameterSetName = 'LiteralPath'
        )]
        [Alias('PSPath')]
        [ValidateNotNullOrEmpty()]
        [String[]]
        $LiteralPath
    )
    
    begin {
        # Some code here
    }

    process {
        if ($PSCmdlet.ParameterSetName -eq 'Path') {
            $allPaths = $Path | ForEach-Object -Process {
                $provider = $null
                $PSCmdlet.SessionState.Path.GetResolvedProviderPathFromPSPath($_, [ref]$provider)
            }
        }
        elseif ($PSCmdlet.ParameterSetName -eq 'LiteralPath') {
            $allPaths = $LiteralPath | ForEach-Object -Process {
                $PSCmdlet.SessionState.Path.GetUnresolvedProviderPathFromPSPath($_)
            }
        }

        foreach ($filePath in $allPaths) {
            # Each $filePath contains the absolute path resolved from the current PowerShell location
        }
    }

    end {
        # Some code here
    }
}

I'm not sure I agree with having a type accelerator for FileInfo specifically, this class is not really something I think we should encourage general use off in PowerShell. Usually the same operations that FileInfo (and DirInfo) are behind the FIleSystem provider included cmdlets like Get-Item, Set-Item, etc. Anyone wishing for these more advanced methods are probably ok with writing the full type name just like any other .NET class without an accelerator.

[mklement0]

Good points, @jborean93: the discrepancy between the working directories makes a solution based on general-purpose (PowerShell-unaware) .NET types impossible.

An additional complication is the lack of support for paths based on PowerShell drives; in the context of the provider cmdlets, this is on output compensated for with instance ETS members such as .PSPath, which you don't get when you directly work with these types.

• For improving the function / script-authoring experience with file-system paths, @rkeithhill has previously suggested introducing a PathParameter attribute that string parameters can be decorated with - see Is it time for a "cmdlet" keyword? #8819 (comment).

• When passing paths to .NET methods, you have to ensure that you always pass full, native paths, to account for the differing working directories.

  • For an existing file-system item this is easily done with Convert-Path.
  • Unfortunately, that currently doesn't work with not-yet-extant items, such as when passing an output file path, which is a real pain point - see Convert-Path should work with non-existent paths #2993.

For general usage, what I do think would make sense is to implement PowerShell-aware analogs to FileInfo and DirectoryInfo:

In fact, a single new class, PSPathInfo that derives from the existing System.Management.Automation.PathInfo class (it is currently sealed, but changing that shouldn't break anyone), may be sufficient:

PathInfo is currently used in Resolve-Path, and has no public constructor - and it has no type accelerator, which PSPathInfo would need, however.

PSPathInfo could build on PathInfo as a provider-agnostic path-information class, with a public constructor that accepts a path string.

It could add generally useful properties, such as .BaseName, .Extension and .ParentPath and .ParentProviderPath, as well as .Exists and .ParentExists (which would be helpful for output items yet to be created), and an .ItemType property that indicates the type of item the path refers to if it exists - along the lines of Unknown (path doesn't exist), File, Directory, Symlink, ... (including subtypes of other providers, which most don't have, however).

(With the proposed class' focus on paths, it wouldn't have to duplicate additional item-specific properties such as .LastWriteTime, ...)

As an alternative to Convert-Path, you could then do the following when calling .NET methods, which is more efficient:

# WISHFUL THINKING
# Equivalent to:
#    [System.IO.File]::ReadAllLines((Convert-Path foo.txt))
[System.IO.File]::ReadAllLines(([PSPathInfo] 'foo.txt').ProviderPath)

If PSPathInfo is made to stringify to its .ProviderPath property (the full, native path, which would be a departure from PathInfo, but to me a defensible one; use .Path for the PowerShell-drive-based path) we could simplify to:

# WISHFUL THINKING
[System.IO.File]::ReadAllLines([PSPathInfo] 'foo.txt')

Additionally, Split-Path could be enhanced to return such instances with the previously proposed -All switch (or, perhaps better: -AsPSPathInfo / -pi) - see #6606.

This would make the following two sample commands equivalent:

# WISHFUL THINKING
([PSPathInfo] 'foo.txt').Extension
(Split-Path -All foo.txt).Extension

Also allowing Resolve-Path to take advantage of the enhanced class would require a new switch (e.g., -AsPSPathInfo / -pi), so as not to break backward compatibility - or, perhaps outputting a class derived from the original, as is the case here, is an acceptable change.

[iRon7]

@jborean93, @mklement0, thanks for your comments.

@jborean93
Your technically argument/limitation about multiple Runspaces is a little above my head, but to your argument:

Anyone wishing for these more advanced methods ...

The issue is not just an accelerator but everything that comes alone (I think I have chosen a bad title for this issue).
Meaning the general argument for this purpose is:

Anyone wishing to improve the performance (where memory usage / the PowerShell pipeline doesn't matter) and therefore pushed* for .Net methods, wishes the same PowerShell experience as it comes to loosely typed variables and defaults.

(*As recommended in PowerShell scripting performance considerations and a lot of StackOverflow answers.)

@mklement0

PSPathInfo could build on PathInfo as a provider-agnostic path-information class, with a public constructor that accepts a path string.

Is indeed something I had in mind (again, I think I have chosen a bad title for this issue, any suggestion for a better one?).

[mklement0]

@iRon7, regarding the rationale for the working directory-discrepancy, necessitated by support for multiple runspaces per process, see #3428.

[mklement0]

As for a title: perhaps something along the lines of "Introduce a PowerShell-aware path-information class for convenient .NET interoperability"?

[iRon7]

@mklement0, thanks, for the runspaces referral, I actually think we are one the same page as I wasn't imaging modifying system.io.fileinfo by itself but actually placing a PowerShell object/class (as e.g. [PSFileInfo]) on top of it where I guess that your suggestion for [PSPathInfo] on top of System.Management.Automation.PathInfo is actually better.