Mysterious different conversion to string[] of seemingly same input data

During investigation of some problem I found that the reason was unexpected different conversion to string[] of seemingly same input data. Namely, in the code below two commands both return the same two items File1.txt and开发者_JS百科 File2.txt. But conversion to string[] gives different results, see the comments.

Any ideas why is it? This might be a bug. If anybody also thinks so, I’ll submit it. But it would nice to understand what’s going on and avoid traps like that.

# *** WARNING
# *** Make sure you do not have anything in C:\TEMP\Test
# *** The code creates C:\TEMP\Test with File1.txt, File2.txt

# Make C:\TEMP\Test and two test files
$null = mkdir C:\TEMP\Test -Force
1 | Set-Content C:\TEMP\Test\File1.txt
1 | Set-Content C:\TEMP\Test\File2.txt

# This gets just file names
[string[]](Get-ChildItem C:\TEMP\Test)

# This gets full file paths
[string[]](Get-ChildItem C:\TEMP\Test -Include *)

# Output:
# File1.txt
# File2.txt
# C:\TEMP\Test\File1.txt
# C:\TEMP\Test\File2.txt

---

Well, I have got some clues (probably posting the question stimulated my thoughts). Yes, this is kind of a trap, not only in PowerShell (but PowerShell makes it possible).

Apparently PowerShell just uses ToString() for conversion. And it was a wrong assumption that System.IO.FileInfo.ToString() returns the FullName. Reflector shows that it returns the base.OriginalPath which is just what was passed in the constructor, not necessary a full path.

Here is the demo:

Set-Location C:\TEMP\Test
[string](New-Object IO.FileInfo File1.txt)
[string](New-Object IO.FileInfo C:\TEMP\Test\File1.txt)
[string](New-Object IO.FileInfo ./..//Test///..Test\File1.txt)

# Output:
# File1.txt
# C:\TEMP\Test\File1.txt
# ./..//Test///..Test\File1.txt

Thus, it looks like the first Get-ChildItem uses just names on creation of FileInfo objects and the second Get-ChildItem with the –Include parameter uses full paths. Is this a bug? It looks debatable now. It might be a feature, questionable, but still with some underlying reasons. I doubt, though…