Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[System.IO.Path]::GetFullPath with a relative path is not honoring the current working directory as documented #10278

Closed
mikebattista opened this issue Aug 1, 2019 · 11 comments
Labels
Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-Answered The question is answered.

Comments

@mikebattista
Copy link

Steps to reproduce

# CD to user home directory then call GetFullPath with a relative path
cd; [System.IO.Path]::GetFullPath("path")

Expected behavior

Per the documentation for GetFullPath and the behavior in Windows PowerShell:

C:\Users\<USER>\path

Actual behavior

A path relative to "c:\windows\system32" is returned regardless of the current working directory.

C:\WINDOWS\system32\path

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.2
PSEdition                      Core
GitCommitId                    7.0.0-preview.2
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
@mikebattista mikebattista added the Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a label Aug 1, 2019
@msftrncs
Copy link
Contributor

msftrncs commented Aug 1, 2019

None of the .NET internal/integral methods recognize the current $PWD to the best of my knowledge. My first experience with this was with the [XML.Document] Save() method.

@vexx32
Copy link
Collaborator

vexx32 commented Aug 1, 2019

I wouldn't be surprised if Windows PowerShell behaves the same, just happens to set the current .NET directory differently.

Just checked it, actually, and using PowerShell Set-Location commands does not affect the current directory from .NET's end. Windows PowerShell does however set the initial location differently.

So this is the same in Windows PS, just with different initial locations between winPS and Core

@mklement0
Copy link
Contributor

Please see #3428.

The short of it:

  • Use Convert-Path to resolve a (relative) PowerShell path to a full one.

  • Because PowerShell allows you to create multiple runspaces in a single process, each with its own current location, while .NET has only one current directory for the whole process ([Environment]::CurrentDirectory), it cannot keep the current PowerShell (filesystem) location in sync with .NET

@mikebattista
Copy link
Author

Ok. I see there is an open doc issue for this. Would be nice to see this captured somewhere discoverable as while always converting to absolute paths works that's not obvious or natural if you haven't been burned by this before.

@msftrncs
Copy link
Contributor

msftrncs commented Aug 1, 2019

@vexx32, the difference is in the setting of the Start in: setting in the start menu shortcut. Windows Powershell has it set to %HOMEDRIVE%%HOMEPATH%, while PowerShell Core doesn't specify it.

This is one of those items 'Hey, you can just access the entire .NET subsystem...', 'Yes, ...but there are so many thing you will need to learn first!'

@msftrncs
Copy link
Contributor

msftrncs commented Aug 2, 2019

@mklement0, just found out Convert-Path is worthless if the path does not yet exist, say when you are using the 'MoveTo()' method.

@mklement0
Copy link
Contributor

@msftrncs, yes, good point, that is a current limitation - see #2993

@mklement0
Copy link
Contributor

mklement0 commented Aug 2, 2019

The short of it is:

To pass not-yet-extant paths (PowerShell Core only, because only .NET Core supports the .GetFullPath() overload with a second argument that specifies the reference directory):

[IO.Path]::GetFullPath($path, $PWD.ProviderPath)

To be fully robust, you additionally need to guard against the current location not being a filesystem location:

[IO.Path]::GetFullPath($path, (Get-Location -PSProvider FileSystem).ProviderPath)

The latter should work in all scenarios - but it doesn't exactly roll off the tongue.

@hunandy14
Copy link

hunandy14 commented Sep 18, 2022

The short of it is:

To pass not-yet-extant paths (PowerShell Core only, because only .NET Core supports the .GetFullPath() overload with a second argument that specifies the reference directory):

[IO.Path]::GetFullPath($path, $PWD.ProviderPath)

To be fully robust, you additionally need to guard against the current location not being a filesystem location:

[IO.Path]::GetFullPath($path, (Get-Location -PSProvider FileSystem).ProviderPath)

The latter should work in all scenarios - but it doesn't exactly roll off the tongue.

Hi
I had the same problem, but with my Powershell version 5.1,
In version 5.1 this method does not work.

Please if there is any alternative to solve it.

Cannot find overload and argument count for 'GetFullPath': '2'.
at line:1 character:1
+ [IO.Path]::GetFullPath($path, $PWD.ProviderPath)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo : NotSpecified: (:) [], MethodException
     + FullyQualifiedErrorId : MethodCountCouldNotFindBest

@djhaskin987
Copy link

[IO.Path]::GetFullPath([IO.Path]::Combine((Get-Location -PSProvider FileSystem).ProviderPath, $path))

That works on PS 5.1 .
@hunandy14 ^^^

@hunandy14
Copy link

hunandy14 commented Nov 30, 2022

[IO.Path]::GetFullPath([IO.Path]::Combine((Get-Location -PSProvider FileSystem).ProviderPath, $path))

That works on PS 5.1 . @hunandy14 ^^^

@djhaskin987
it work ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Thank you very much

zeroSteiner added a commit to zeroSteiner/metasploit-framework that referenced this issue May 23, 2023
JustAnda7 pushed a commit to JustAnda7/metasploit-framework that referenced this issue Jun 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-Answered The question is answered.
Projects
None yet
Development

No branches or pull requests

7 participants