正如Hennes正确指出的,在这种情况下,这显然与从DOS时代继承的特殊含义有关aux
。但是,对于以后在阅读中遇到麻烦的读者,我想添加另一种可能的情况,即可以看到这种行为。
那是在创建带有尾点的文件时。还有更多异国情调的案件。但是filename.ext.
会是这样的文件名,通常无法从Win32子系统中删除。这就是来自Karan的技巧。他使用的名称在传递到Win32子系统下面的层之前,将从\\?\C:\...
形式更改为“本机”(这也是文件系统过滤器驱动程序看到它的方式)形成\??\C:\...
。而根据Windows的版本,这可以是所谓的对象目录(使用Sysinternals / Microsoft的WinObj窥视对象管理器名称空间)或符号链接(不要与自Vista以来在NTFS中名称相同的实体混淆)到另一个对象目录,例如\DosDevices
。后者只是一个名称,它描述了对象管理器名称空间中Win32进程默认可见的部分。有关更多详细信息,请查阅系列书籍Windows Internals或阅读有关路径解析的文章,尤其是在Google Project Zero (《 Win32到NT路径转换的Win32权威指南》)上。特别是,您可能要注意Win32文件命名空间和Win32设备命名空间之间的区别。
现在如何首先创建这样的文件?有几种可能性。
- 一个Win32程序使用
\\?\X:
路径名的前缀,以便将可用的路径长度从260个字符扩展到大约32767个字符(请参见脚注1!),首先创建了该文件,从而规避了Win32子系统的某些限制。
- 植根于不同子系统的程序。创建了以前的POSIX子系统(后来为Interix,现在为SUA),OS / 2子系统(已不复存在,但以前在NT 3.51上存在)或某个并非Windows意义上的子系统的层(据我所知Cygwin)文件或文件夹。同样,Windows 10上的WSL(Linux的Windows子系统)现在是另一个候选对象。
- 创建了另一个操作系统(例如,并行Linux引导)。
- 它是位于非Windows服务器上的网络共享上的文件。
最后两点也暗示了所提到的一种补救措施:引导非Windows live CD并删除文件。
该问题实际上可以与旧的非Unicode Win32程序面临来自多个代码页的文件名的情况相比。通常,它无法“找到”其中的一些,因为每个相应的ANSI代码页只能容纳256个字符,而从理论上讲,UTF-16(而不是其子集UCS-2)可以编码几乎无限数量的代码点(在unicode.org和Wikipedia上阅读有关该主题的信息)。
希望这有助于更多地了解潜在问题。不想将此长答案编辑为其他答案之一,尽管它只是对它们的补充。没有这个答案,其他答案是完全有效的。
脚注1:路径中的最大字符数不是绝对的,因为接近绝对最大值(32767个字符)的路径可能会被对象管理器和文件系统过滤器或文件系统本身(例如重新解析点)扩展。