Powershell: Powershell 7.0-preview1 regression: Get-ChildItem returns full paths instead of relative paths.

[TheGoddessInari]

This breaks vcpkg's scriptsbootstrap.ps1. I imagine it breaks any script assuming the previous behavior.

Conclusively, Get-ChildItem is returning full paths instead of relative paths.

It's most obvious on Microsoft's own vcpkg's bootstrap, since it fails immediately.

Steps to reproduce

cd \pathtovcpkg
scripts\bootstrap.ps1 -verbose

Expected behavior

VERBOSE: Looking for Windows 10 SDK
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\sdkddkver.h - Found
VERBOSE: Found 10.0.18362.0
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\windows.h - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared\sdkddkver.h - Found
VERBOSE: Found 10.0.17763.0
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\sdkddkver.h - Found
VERBOSE: Found 10.0.18362.0
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\windows.h - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared\sdkddkver.h - Found
VERBOSE: Found 10.0.17763.0
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um\windows.h - Not Found
VERBOSE: C:\Program Files\Windows Kits\10\Include - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\sdkddkver.h - Found
VERBOSE: Found 10.0.18362.0
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\windows.h - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared\sdkddkver.h - Found
VERBOSE: Found 10.0.17763.0
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um\windows.h - Not Found
VERBOSE:

Actual behavior

VERBOSE: Looking for Windows 10 SDK
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um\windows.h - Not Found
VERBOSE: C:\Program Files\Windows Kits\10\Include - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include - Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\windows.h - Not Found
VERBOSE: C:\Program Files (x86)\Windows Kits\10\Include\C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um\windows.h - Not Found
VERBOSE:

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.1
PSEdition                      Core
GitCommitId                    7.0.0-preview.1
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

[doctordns]

Looking at this, If I look at a file system object with Get-ChildItem, I note that in PowerShell V 7, the object's Parent property is a full pathname (same in 6.2), but a relative pathname in V5.1. This is not really a regression in 7.0.

[rjmholt]

@TheGoddessInari would you be able to provide a standalone repro? It looks like I'd need a C++ project to reproduce this currently

[doctordns]

The problem is easy to reproduce. Get-ChildItem is returning a different value for the Parent property of the System.IO.Directoryinfo object between Windows PowerShell and Powershell 6.2, and 7 (and probably also earlier versions of 6.x).

I have a folder, C:FooTestTest2, and the following happens:
````powershell

In WindowsPowerShell 5.1

PS [C:foo> ]> get-item c:footesttest2 | fl name, parent
Name : test2
Parent : test

In PowerShell 6.2, and 7:

PS [C:foo> ]> get-item c:footesttest2 | fl name, parent
Name : test2
Parent : C:footest
````
I suspect the script that is having the issue is adding the parent name returned to a string to create a path, and due to this change in System.IO.DirectoryInfo this no longer works the same way, hence the reported error.

Not sure if this is a bug in the cmdlet or a feature (and thus a breaking change).

[vexx32]

I'm wondering if this change might originate in .net Core?

[rjmholt]

So I did a little bit of digging:

• gci returns FileSystemInfo objects (not strings), as does (gci).Parent
• The formatting in the default formatter in PowerShell still uses the relative name:

> [System.IO.DirectoryInfo]::new($PWD).Parent

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-r---         5/31/2019 10:12 PM                Users

> [System.IO.DirectoryInfo]::new($PWD).Parent.Name
Users

> gci | select -First 1 | % { $_.Parent }

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----          6/3/2019 11:23 AM                me

> gci | select -First 1 | ft name,parent

Name   Parent
----   ------
.Azure C:\Users\me

• But, [System.IO.DirectoryInfo]::new($PWD).Parent.ToString() has changed from relative to absolute. That appears to be because DirectoryInfo.ToString() returns the original path used in the constructor.
• Since this is a type created purely in .NET (and we don't control the constructor for Parent), this looks like a .NET regression that nobody caught
• The strange part is they already hit this once and added tests for it. So I'll open an issue and check

[rjmholt]

Looks like .NET is leaning toward WontFix.

In that case, we should:

• Investigate changing LanguagePrimitives so that converting a DirectoryInfo to a string uses Name rather than ToString()
• Investigate investment in @rkeithhill's suggested [Path()] attribute (or a similar parameter processing attribute)
• Update any relevant documentation

[doctordns]

Is it worth pointing this out as a Breaking Issue for PowerShell 7?

[rjmholt]

Is it worth pointing this out as a Breaking Issue for PowerShell 7?

It'll likely go in the changelog of the next release as a breaking change - @joeyaiello and @TravisEz13 are most familiar with our changelog processes.

[TheGoddessInari]

It's worth noting that Powershell 6.0 also returns relative.
I'm also not sure what the point of the press release for Powershell 7 saying it's supposed to be a drop-in replacement for Windows Powershell is if it's going to break scripts that use any of these common functions, even those that were already modified to be clean on both Powershell 5.0 and 6.0.
As far as I can tell, it was never listed as a breaking change for 6.1 or 6.2, and it breaks Powershell scripts that even Microsoft ships.

[rjmholt]

Duplicate of https://github.com/PowerShell/PowerShell/issues/7132