PowerShell doesn't set current working directory correctly

[SetTrend]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Writing a binary module I noticed that the current working directory isn't set correctly on Windows.

[System.Environment]::CurrentDirectory always returns C:\Windows\system32, no matter what.

Expected behavior

PS> Set-Location 'C:\Temp'
PS> [System.Environment]::CurrentDirectory
C:\Temp

Actual behavior

PS> Set-Location 'C:\Temp'
PS> [System.Environment]::CurrentDirectory
C:\Windows\system32

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.3
PSEdition                      Core
GitCommitId                    7.3.3
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

[rhubarb-geek-nz]

I believe this is working as designed.

PowerShell maintains its own version of working directory. PowerShell is a multithreaded system, the operating system concept of working directory belongs to the process.

Basically that does not work well with multiple parallel threads each trying to change and manage the current working directory for their own purposes.

But if you launch a new process, eg a command prompt or shell from PowerShell it will get PowerShell's version of the current directory as it's current directory.

[SetTrend]

Then how is a binary module supposed to retrieve the current working directory?

[rhubarb-geek-nz]

Then how is a binary module supposed to retrieve the current working directory?

What kind of binary module?

Let's say that it should not assume, and should be given the directory to use as current directory as a parameter if it is to be a good PowerShell citizen.

[mklement0]

Related:

• "Actual" current directory and PowerShell current directory mismatch when using .NET BCL methods #3428 (original issue, explains the design rationale that @rhubarb-geek-nz has summarized above)
• PowerShell doesn't call SetCurrentDirectory() when location changes nor sets $env:PWD #17149 (follow-up issue, debatable plan to make the main thread only sync with the process-wide working dir.

Then how is a binary module supposed to retrieve the current working directory?

Derive your binary cmdlet from PSCmdlet (rather than from Cmdlet), which gives you access to the PowerShell session state - see below.

[jborean93]

I've always found the answer on this SO post to be quite helpful in trying to reimplement the Path and LiteralPath parameter set in binary cmdlets https://stackoverflow.com/questions/8505294/how-do-i-deal-with-paths-when-writing-a-powershell-cmdlet. It shows you how you can expand the paths given from a relative/glob-like string to the absolute path on the filesystem. I even create a base class in which my cmdlets inherit from which include a helper function to convert the 2 path parameters into a single array of resolved paths https://github.com/jborean93/PowerShell-OpenAuthenticode/blob/11e21d87d59e75d8d7967ebe7a371347540f1d83/src/OpenAuthenticode/OpenAuthenticodeSignature.cs#L25-L61.

Stack Overflow

How do I deal with Paths when writing a PowerShell Cmdlet?

What is the proper way to receive a file as a parameter when writing a C# cmdlet? So far I just have a property LiteralPath (aligning with their parameter naming convention) that is a string. This...

GitHub

PowerShell-OpenAuthenticode/OpenAuthenticodeSignature.cs at 11e21d87d59e75d8d7967ebe7a371347540f1d83 · jborean93/PowerShell-OpenAuthenticode

Cross platform PowerShell implementation of Authenticode signing and verification - PowerShell-OpenAuthenticode/OpenAuthenticodeSignature.cs at 11e21d87d59e75d8d7967ebe7a371347540f1d83 · jborean93/...

[ThomasNieto]

The easiest way I've found for a binary cmdlet to get the current working directory is:

this.SessionState.Path.CurrentFileSystemLocation.Path;

https://learn.microsoft.com/en-us/dotnet/api/system.management.automation.pathintrinsics.currentfilesystemlocation?view=powershellsdk-7.2.0#system-management-automation-pathintrinsics-currentfilesystemlocation

PathIntrinsics.CurrentFileSystemLocation Property (System.Management.Automation)

Gets the current location for the file system provider.

[SetTrend]

@rhubarb-geek-nz:

I'm providing something similar to a Move-Item Cmdlet. One of the arguments is a target file to handle. So, that's intrinsic functionality to the binary module.

@mklement0:

I would have expected an expression like MyInvocation.PSScriptRoot to be successful, but to no avail.

I couldn't find a way to create unit test session in Visual Studio 2022 that's calling a binary module's Cmdlet, allowing me to debug into the Cmdlet code by debugging the unit test. So, I'm not able to inspect any session state variable in my binary module.

@ThomasNieto:

Marvellous! Great solution! Thanks!!! 👍👍👍

---

Nonetheless, I believe it would be less awkward and opaque if the first thread running when the Shell is launched was to immediately call something like [System.Environment]::CurrentDirectory = this.SessionState.Path.CurrentFileSystemLocation.Path;. That wouldn't involve any session issues.

Anyway, if current working directory is an issue due to threading issues, I propose to have the CWD being thread local, being initialized on thread start by the creating process.

[mklement0]

Good point, @ThomasNieto - that's the best solution. Worth adding that if you want a native file-system path (rather than one potentially based on a PS-only drive), use this.SessionState.Path.CurrentFileSystemLocation.ProviderPath;
(And if you want the current location even if it isn't a file-system location, use this.SessionState.Path.CurrentLocation)

[mklement0]

@SetTrend

I would have expected an expression like MyInvocation.PSScriptRoot

That gives you the directory in which the calling script happens to be located.

I believe it would be less awkward and opaque if the first thread running when the Shell is launched was to immediately call something like [System.Environment]::CurrentDirectory = this.SessionState.Path.CurrentFileSystemLocation.Path;.

That's the subject of #17149, but it presents its own challenges, as code then behaving differently depending on whether it runs on the main thread or not is obscure too.

I propose to have the CWD being thread local, being initialized on thread start by the creating process.

That's not possible, unfortunately, because at the process level there can only be one working directory, i.e. it invariably applies to all threads running in the process.

PowerShell in essence already has thread-local working directories, but it is a PowerShell-specific concept that only native PowerShell commands know of and honor.

It is therefore a problem for all in-process calls to non-PowerShell code, notably when calling .NET APIs with relative paths.
(By contrast, when calling external programs, PowerShell sensibly makes its (thread-local) working directory the child process' working directory, so there's no problem there).

[SetTrend]

Thanks for clarifying, @mklement0.

Yet, isn't this a comon issue with all kinds of programs? I remember writing multi-threaded code for decades, and it's been an ongoing challenge to not alter non thread-safe properties accidentally and to cache non thread-safe properties in a thread once read. So, does it make sense to bother here when basically no other platform does?

[mklement0]

So, does it make sense to bother here when basically no other platform does?

I'm afraid I don't understand the question.

Note that PowerShell is unusual in that is both a shell and a sophisticated automation framework that in effect allows multiple shell sessions in a single process.

In a shell, the current working directory is an important concept, so any given PowerShell thread (runspace) in a given process must be able to use and modify it, without affecting other threads.

[rhubarb-geek-nz]

Yet, isn't this a common issue with all kinds of programs? ... .So, does it make sense to bother here when basically no other platform does?

Absolutely it does, the reason is that PowerShell is attempting to provide a reliable multithreaded programming environment. If it is a well-known problem that process wide current working directory does not work well with threads then it means it should not be part of a reliable multithreaded programming environment.

With references to Raymond.

https://devblogs.microsoft.com/oldnewthing/20210816-00/?p=105562 from 2021

https://devblogs.microsoft.com/oldnewthing/20101109-00/?p=12323 from 2010

The Old New Thing

What are these dire multithreading consequences that the GetFullPathName documentation is trying to warn me about? - The Old New Thing

The current directory is volatile, so plan accordingly.

The Old New Thing

The curse of the current directory - The Old New Thing

The current directory is both a convenience and a curse. It’s a convenience because it saves you a lot of typing and enables the use of relative paths. It’s a curse because of everything else. The root cause of this curse is that the Windows NT family of operating systems keeps open a handle to the process’s current directory.