"Actual" current directory and PowerShell current directory mismatch when using .NET BCL methods #3428

Activity

1. PetSerAl commented on Mar 26, 2017

   

   PetSerAl

   on Mar 26, 2017

   Contributor

   More actions

   If I have process with multiple Runspaces and each one have different current location. Which one $pwd should be honored by .NET methods?
2. antiufo commented on Mar 26, 2017

   

   antiufo (antiufo)

   on Mar 26, 2017

   Last edited by antiufo

   Author

   More actions

   Possible solutions I can think of:

   • Leave the behavior as it is
   • Take a process-wide lock when BCL methods are directly invoked (except for cmdlets), if multiple runspaces exist (I don't know to what extent it would impact the performance)
   • Switch the current directory to a dummy, default directory whenever the number of runspaces > 1 (to make the mistake clear)
   • Only honor the $pwd of the main runspace
   • Provide something like using-current-directory{ [IO.File]::WriteAllText() } that acts as a process-wide lock that sets the real current directory.
3. Ilya (iSazonov)

   added

   Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif

   on Mar 26, 2017
4. PetSerAl commented on Mar 26, 2017

   

   PetSerAl

   on Mar 26, 2017

   Contributor

   More actions

   antiufo (@antiufo) Process-wide lock will not going to work, unless everyone agreed to use it and performance implication are not very good. Also, not every process host PowerShell just for sake of hosting PowerShell. Process may have its own work to do and unlikely be happy if you just change its working directory to dummy one. And as Runspaces can come and gone at process wish, it may be hard to say which one is main.
   Besides, IMHO, there is good enough solution for this already:

   PS C:\Users\PetSerAl> function ConvertTo-FileSystemPath {
   >>     param($PSPath)
   >>     $PSProvider = $null
   >>     $Result = $ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath($PSPath, [ref]$PSProvider, [ref]$null)
   >>     if($PSProvider.ImplementingType -eq [Microsoft.PowerShell.Commands.FileSystemProvider]) {
   >>         $Result
   >>     } else {
   >>         Write-Error 'Not filesystem provider'
   >>     }
   >> }
   PS C:\Users\PetSerAl> New-PSDrive Win FileSystem C:\Windows | Out-Null
   PS C:\Users\PetSerAl> ConvertTo-FileSystemPath qwe
   C:\Users\PetSerAl\qwe
   PS C:\Users\PetSerAl> cd \
   PS C:\> ConvertTo-FileSystemPath asd
   C:\asd
   PS C:\> ConvertTo-FileSystemPath Win:\zxc
   C:\Windows\zxc
   PS C:\> ConvertTo-FileSystemPath HKLM:\SOFTWARE
   ConvertTo-FileSystemPath : Not filesystem provider
   At line:1 char:1
   + ConvertTo-FileSystemPath HKLM:\SOFTWARE
   + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
       + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,ConvertTo-FileSystemPath

   👍React with 👍1Reacted by Michael Klement
5. BrucePay commented on Mar 28, 2017

   

   Bruce Payette (BrucePay)

   on Mar 28, 2017

   Collaborator

   More actions

   This behavior is by design and it's been this way since version 1.0. We considered options like those proposed above but none of them were viewed as satisfactory for various reasons. Acquiring a global lock, then setting the process pwd, then calling a method is a lot of overhead when the majority of .NET APIs don't depend on pwd. Doing this also greatly complicates a host application's (e.g. exchange UI, VMM console, etc.) use of the current working directory since it can't depend on PWD anymore. The workaround for .NET APIs that take paths is to, as mentioned in another comment, resolve the path before passing It to the API which need not be onerous e.g. WriteAllText("$pwd\fileincurrentdir.txt")
6. Ilya (iSazonov)

   added

   Resolution-By DesignThe reported behavior is by design.The reported behavior is by design.

   on Mar 28, 2017
7. Ilya (iSazonov)

   closed this as completedon Mar 31, 2017
8. mklement0 commented on Jun 27, 2018

   

   Michael Klement (mklement0)

   on Jun 27, 2018

   Last edited by mklement0

   Contributor

   More actions

   Too bad that there's no good solution, because the behavior is a perennial pain point.

   The "$pwd\fileincurrentdir.txt" shortcut is alluring, but - aside from assuming that the current location is a filesystem location (an assumption that will often, but not always hold) - it fails with current filesystem locations based on PS drives.

   Remedying that doesn't take much extra effort, fortunately:

   [io.file]::WriteAllText($PWD.ProviderPath + '/fileInCurrentDir.txt', 'foo')

   If you also want to guard against the current location being on a different provider's drive:

   [io.file]::WriteAllText((Get-Location -PSProvider FileSystem).ProviderPath + '/fileInCurrentDir.txt', 'foo')

   PetSerAl's ConvertTo-FileSystemPath helper function is the most robust and flexible approach, but anything that doesn't ship with PowerShell is unlikely to see widespread adoption.

   However, what this function does could be folded into the standard Convert-Path cmdlet - see #7197
9. essentialexch commented on Dec 14, 2023

   

   Michael B. (essentialexch)

   on Dec 14, 2023

   More actions

   I think you've missed a use-case, and that's libraries that don't know anything about PS.

   For example, Terminal.Gui has at least three APIs (related, but still - FileDialog, OpenDialog, SaveDialog) that initialize the displayed folder from [system.environment]::currentdirectory. So I have to set it to what PS thinks the working directory is before initializing any of those APIs.