Document the pitfalls of passing relative filesystem paths to .NET methods / constructors

[mklement0]

.NET uses the current process' current directory (working directory) to resolve filesystem paths, as reflected in [Environment]::CurrentDirectory

Every PowerShell runspace maintains its own current directory (location) that can deviate from the process's, which can have surprising results when you pass relative paths to .NET methods and constructors.

Here's a simple example:

# Assume that PowerShell's location is the current user's home directory, 
# e.g., /Users/jdoe
PS> Set-Location /; [io.fileinfo]::new('foo').fullname
/Users/jdoe/foo  # !! Resolved relative to /Users/jdoe, not /

This pitfall should be documented in about_Methods and about_Locations.

PowerShell/PowerShell#3428:

• contains a discussion of why, unfortunately, always keeping the two locations in sync is not an option

• offers workarounds.

PowerShell/PowerShell#7197 suggests enhancing the Convert-Path cmdlet to make it easier to resolve relative paths and paths based on custom PS drives to full filesystem paths so that they can be safely passed to .NET methods.

Issue Details

Version(s) of document impacted

• Impacts 6.1 document
• Impacts 6.0 document
• Impacts 5.1 document
• Impacts 5.0 document
• Impacts 4.0 document
• Impacts 3.0 document

[LeGEC]

I see the checkboxes ticked, yet the issue is still open, so I'm guessing the matching documentation is not published yet ?

Where can I read about said pitfalls ?