我打错了一个path，而不是c:\foo.txt写了c:foo.txt 。 我预料它要么失败，要么parsing为c:\foo.txt ，而是似乎在当前用户的home文件夹中parsing为foo.txt 。
Powershell返回：
PS C:\> [System.IO.Path]::GetFullPath("c:\foo.txt") c:\foo.txt PS C:\> [System.IO.Path]::GetFullPath("c:foo.txt") C:\Users\Administrator\foo.txt PS C:\> [System.IO.Path]::GetFullPath("g:foo.txt") G:\foo.txt
从命令行运行explorer.exe并将以上任何一个结果传递给C：\ Users \ Administrator \ Documents以打开。
我还没有find任何文件，我完全困惑，请解释行为。
当您使用驱动器号指定路径但没有初始反斜杠时， 通常将其解释为指定驱动器上当前目录的相对路径。 特别是，这是普通的Win32 API文件函数将如何解释它; 因此，大多数将未经修改的文件路径传递给Win32文件函数的软件也会这样做。
在我的机器上，这在PowerShell中按预期工作，除了一个并发症：
C:\Users\social>powershell Windows PowerShell Copyright (C) 2009 Microsoft Corporation. All rights reserved. PS C:\Users\social> [System.IO.Path]::GetFullPath("c:foo.txt") C:\Users\social\foo.txt PS C:\Users\social> cd \ PS C:\> [System.IO.Path]::GetFullPath("c:foo.txt") C:\Users\social\foo.txt PS C:\>
我们在这里看到的是，当我们在PowerShell中更改当前目录时，它实际上并不改变当前目录 。 也就是说，PowerShell对于当前目录是什么有自己的想法，但是并没有把这个改变告诉Windows。 您可以使用Process Explorer（可从Microsoft网站下载）进行确认。 在上述情况下，即使在使用cd ，PowerShell进程的实际当前目录仍然是C:\Users\social 。
你也提到资源管理器。 据我所知，资源管理器对自己的路径进行了自己的验证，无论出于何种原因，它都不允许驱动相对路径。 如果路径不被视为有效，或者不指向实际的文件/文件夹，则默认操作是打开用户的“文档”文件夹。
这是标准的DOS / Windows行为，一直是这样的。 打开命令行并查看：
C:\Users\Tim>d: # change current drive to d: D:\>c: # change back to c: - back in the same directory C:\Users\Tim>cd d:\users # change current directory ON D: C:\Users\Tim>cd \ # still same directory - backslash leads to top dir C:\>d: # change current drive to d: D:\Users> # notice that we're now in the directory D:\Users
驱动器号始终引用该驱动器的当前目录; （引导）反斜杠会将您引导至顶层目录。
它使用该驱动器上的当前工作目录。 每个进程“记住”每个驱动器的当前工作目录：
C:\> cd somepath\subdir C:\somepath\subdir> d: D:\> dir c:subsubdir <-- refers to C:\somepath\subdir\subsubdir