为什么在尝试删除该文件时该文件显然不存在？
Ale*_*lex 9 windows-7 file-permissions
大约一个月前，我在 Cygwin 的一个文件夹中解压了 Linux 源代码（我很好奇它是否可以与 MinGW 一起编译，因为我的另一台运行 Linux 的计算机是一个缓慢的单核 Sempron）。我尝试删除它，但还剩1个文件，它不会删除...
Cygwin 驻留C:\cygwin在C:\cygwin\src\linux-3.7.1. 它没有编译...所以我尝试删除该文件夹。一切都很顺利，直到最后，当我意识到并非所有文件都被删除时。我linux-3.7.1再次尝试删除文件夹，并弹出一个错误：
我打开文件夹，发现还剩下 1 个源文件：aux.c，在C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.
它不会：
- 删除
- 打开
- 移动
一般属性：
安全属性：
如何删除此文件？
Hen*_*nes 15
您遇到的问题是由于古老的 DOS 保留。
以下列表中的文件具有特殊含义。其中一部分仍然存在于现代 Windows 版本中：
CON、PRN、AUX、CLOCK$、NUL、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9 LPT1、LPT2、LPT3、LPT4、LPT5、LPT6、LPT7、LPT8 和 LPT9。
删除它们的最简单方法是启动一个不将这些文件名视为特殊文件名的操作系统。（例如启动任何非 Windows liveCD）。
[编辑] 在 win7-x86 Ultimate 上完成的测试：
创建一个简单的测试文件：
S:\>copy con foo.c
测试
^Z
已复制 1 个文件。
检查内容：
S:\>输入 foo.c 测试
现在使用aux .c
S:\>copy con aux.c
^Z
该系统找不到指定的文件。
已复制 0 个文件。
似乎部分 Windows 仍然向后兼容。
- 它仍然以 aux 开头，旧的文件名样式是“文件名”点“扩展名”。我刚刚在 win7 上测试了 `copy con aux.c` 并且失败了。（`copy con test.c` 确实有效）。 (3认同)
Kar*_*ran 15
从（提升的）命令提示符试试这个：
del \\?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c
- 卡兰：哦，聪明。避免使用普通的文件系统命名空间。@Alex Yan：文件夹中没有打开cmd窗口？ (3认同)
在这种情况下，正如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 设备命名空间之间的区别。
现在如何首先创建这样的文件？有几种可能性。
- 一个使用
\\?\X:路径名前缀的 Win32 程序将可用路径长度从 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 个字符）的路径很可能会被对象管理器和文件系统过滤器或文件系统本身（例如重解析点）扩展.