Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Strange behavior with Get-ChildItem #5269

Copy link
Copy link
@LaurentDardenne

Description

@LaurentDardenne
Issue body actions

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 -Recurse

Actual 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
Reactions are currently unavailable

Metadata

Metadata

Assignees

No one assigned

    Labels

    Breaking-Changebreaking change that may affect usersbreaking change that may affect usersIssue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aResolution-FixedThe issue is fixed.The issue is fixed.WG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.