Powershell: copy from \\fake\share doesn't output error message

[SteveL-MSFT]

Steps to reproduce

copy \\fake\share\* .

Expected behavior

cmd returns "The network path was not found."

Actual behavior

No error message, no output

Environment data

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
GitCommitId                    v6.0.0-beta.2-61-g36c51f2f0760c2346505687ecf8e945984a1506a-dirty
OS                             Microsoft Windows 10.0.16225
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

TFS:12196563

[Tadas]

Same with Get-ChildItem - it doesn't show an error
Get-ChildItem \\fake\share\*

Removing the wildcard makes it work as expected

PS> Get-ChildItem \\fake\share\
Get-ChildItem : Cannot find path '\\fake\share\' because it does not exist.
At line:1 char:1
+ Get-ChildItem \\fake\share\
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (\\fake\share\:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

I'll give this one a shot over the weekend, I think I know where the problem is.

[Tadas]

I'd say the problem lies somewhere in LocationGlobber.cs and how it handles different types of paths. Get-ChildItem C:\fake\path\* works as expected while Get-ChildItem \\fake\path\* does not.

But that is as far as I got - couldn't wrap my head around LocationGlobber 😵

[SteveL-MSFT]

@Tadas thanks for looking into it anyways :)

[zhenggu]

on mac, Get-ChildItem //f/* also have this issue.

[SteveL-MSFT]

I think a non-terminating error should be returned

[iSazonov]

Seems we have conclusion that for wildcards we should return nothing.

/cc @mklement0

[mklement0]

@iSazonov:

Returning nothing for non-matching wildcards only applies if the literal path of the part - \\fake\path in this case - does exist; if it doesn't, I'd expect an error too.

@zhenggu:

on mac, Get-ChildItem //f/* also have this issue.

Indeed - very curious, given that // has no special meaning on Unix-like platforms and _should_ just be treated as a single /. In fact, that applies even to 3+ consecutive / chars.