Repository navigation
Strange behavior with Get-ChildItem #5269
Description
Steps to reproduce
$Path='C:\temp'
#remove-item "$Path\TestPS" -recurse
md "$Path\TestPS"
get-childitem -path "$Path\TestPS\F*.txt" -File -Recurse #OK no file
md "$Path\TestPS\D1"
get-childitem -path "$Path\TestPS" -Directory -Recurse #Ok one directory
get-childitem -path "$Path\TestPS\*" -Directory -Recurse #NOK no result
"Test" > "$Path\TestPS\D1\File1.txt"
get-childitem -path "$Path\TestPS\F*.txt" -File -Recurse #OK one file
get-childitem -path "$Path\TestPS" -File -Recurse #OK one file
get-childitem -path "$Path\TestPS\*" -File -Recurse #NOK no result
#Add a file into the 'root' of the search
"Test" > "$Path\TestPS\File2.txt"
get-childitem -path "$Path\TestPS\*" -File -Recurse #OK two files !!! Different !!!
get-childitem -path "$Path\TestPS\*" -Directory -Recurse #OK one directory !!! Different !!!
remove-item "$Path\TestPS\File2.txt"
#The 'root' of the search is empty
get-childitem -path "$Path\TestPS\*" -File -Recurse #NOK no result
get-childitem -path "$Path\TestPS\*" -Directory -Recurse #NOK no result
#original path
#Get-ChildItem -Path 'C:\Users\laurent\AppData\Local\Mozilla\Firefox\Profiles\*.default*' -File -Rec
#it works
#Get-ChildItem -Path 'C:\Users\laurent\AppData\Local\Mozilla\Firefox\Profiles\*.default*' -Rec|Where-Object {-not $_.PSIsContainer}Expected behavior
The following calls must return existing files or directories :
get-childitem -path 'C:\Temp\TestPS\*" -File -Recurse
get-childitem -path 'C:\Temp\TestPS\*" -Directoyr -RecurseActual behavior
When the 'root' of the search ('C:\Temp\TestPS') is empty, the search do not return all entries :
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-beta.9
PSEdition Core
GitCommitId v6.0.0-beta.9
OS Microsoft Windows 6.1.7601 S
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.10032.0, 6.0.0}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Same problem with For Windows PowerShell v 5.1.14409.1012 :
> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14409.1012
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.14409.1012}
BuildVersion 10.0.14409.1012
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Activity
SteveL-MSFT commentedon Oct 31, 2017
It seems that the behavior is that if you have a wildcard, then the recursion is applied to the results of that wildcard expansion. Assume a folder structure like:
gci testPS\*returnsd1as expectednow, if you use
gci testPS\* -recurse, the-recurseis applied tod1, nottestPSdue to the wildcard andd2is returned.I agree that the behavior may not seem intuitive, but it does seem (somewhat) logical. I'd be concerned that a change here would not be a breaking change worth making. Perhaps we should just update the documentation?
LaurentDardenne commentedon Nov 2, 2017
Yes.
Are these statements equivalent (with my first exemple) ?
Are these statements equivalent (with my first exemple) ?
If for this last example these statements are equivalent, in my case the resultat is different.
SteveL-MSFT commentedon Nov 3, 2017
I missed the details about
Fileand agree that it's broken.LaurentDardenne commentedon Feb 8, 2018
Steve Lee (@SteveL-MSFT) this fix do not should be backported to Windows PowerShell 5.1 ?
SteveL-MSFT commentedon Feb 8, 2018
Laurent Dardenne (@LaurentDardenne) the concern would be that this is a breaking change so at this time not considered to be ported to 5.1
LaurentDardenne commentedon Feb 9, 2018
OK, thanks.
How to find the list of these bugs / difference ?
Can the addition of a label be considered here or should we duplicate this issue on Uservoice?
SteveL-MSFT commentedon Feb 9, 2018
Laurent Dardenne (@LaurentDardenne) the label indicates we're considering backporting it to Windows PowerShell 5.1. At the time of actual port, we'll determine if it's too risky to port due to risk of regression (since the PSCore6 code base has now deviated quite a bit from the Windows PowerShell code base). Perhaps I'll create a new label
Ported-WindowsPowerShell51to indicate PRs that have been ported.LaurentDardenne commentedon Feb 10, 2018
Steve Lee (@SteveL-MSFT)
There is the label '_Breaking-Chang_e' which is very useful when porting code v5.n to v6.n
A 'Ported-WindowsPowerShell51' label can be useful information.
This fix does not have the 'Breaking-Change' label, but in the case of a 6.n code port, (based on this corrected behavior) to-> 5.n, how do I find these cases?
A 'NotPorted-WindowsPowerShell51' label ? :-)
Or a note inside the Changelog.md file ?
It is information intended for the users and not for the monitoring of the project.
SteveL-MSFT commentedon Feb 12, 2018
Laurent Dardenne (@LaurentDardenne) this issue should have had the
Breaking-Changelabel, was just missed. We usually have theBreaking changesat the top of the ChangeLog. We have a work item to have better documentation on porting scripts/modules from 5.1 to 6.