为什么尝试删除该文件时它显然不存在?

为什么尝试删除该文件时它显然不存在?

大约一个月前,我在 Cygwin 的一个文件夹中解压了 Linux 源代码(我很好奇它是否能用 MinGW 编译,因为我另一台运行 Linux 的计算机是一台速度很慢的单核 Sempron)。我尝试删除它,但还剩下一个文件,无法删除...

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

它不会:

  • 删除
  • 打开
  • 移动

一般性质:

一般的

安全属性:

安全

我如何删除这个文件?

答案1

从(提升的)命令提示符尝试此操作:

del \\?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c

答案2

您遇到的问题是由于古老的 DOS 保留造成的。

以下列表中的文件具有特殊含义。其中一部分在现代 Windows 版本中仍然存在:

CON、PRN、辅助、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:\>复制 con foo.c
测试
^Z
        已复制 1 个文件。

检查内容:

S:\>类型 foo.c
测试

现在辅助。C

S:\>复制 con aux.c
^Z
该系统找不到指定的文件。
        已复制 0 个文件。

看来 Windows 的某些部分仍然向后兼容。

答案3

在这种情况下,显然是关于aux从 DOS 时代继承的特殊含义, 作为亨内斯正确指出。但是,对于将来遇到此问题的读者,我想添加另一个可以看到此行为的可能情况。

这就是创建的文件带有尾部点的情况。还有更奇特的情况。但filename.ext.会是这样的文件名,并且通常不能从 Win32 子系统中删除。这就是来自卡兰进入。他/她使用一个名称,在传递到 Win32 子系统下面的层之前,该名称将从其\\?\C:\...形式更改为“本机”(这也是文件系统过滤驱动程序看到它的方式)形式\??\C:\...。而根据 Windows 版本的不同,这可能是所谓的对象目录(使用 Sysinternals/Microsoft 中的 WinObj 查看对象管理器命名空间)或符号链接(不要与 Vista 以来 NTFS 中同名的实体混淆)到另一个对象目录,例如\DosDevices。后者只是一个名称,描述了默认情况下 Win32 进程可见的对象管理器命名空间部分。有关更多详细信息,请查看书籍系列 Windows Internals 或阅读 Google 的 Project Zero 上有关路径解析的特别内容(Win32 到 NT 路径转换的权威指南)。你可能需要特别注意以下两者之间的区别:Win32 文件命名空间Win32 设备命名空间

那么首先如何创建这样的文件呢?有几种可能性。

  1. 一个 Win32 程序使用\\?\X:路径名前缀来将可用路径长度从 260 个字符扩展到大约 32767 个字符(参见脚注 1!),并首先创建了该文件,从而规避了一些Win32 子系统的局限性。
  2. 一个植根于不同子系统的程序。前一个 POSIX 子系统(后来英特里克现在是 SUA)、OS/2 子系统(早已消失,但曾经存在于 NT 3.51 中)或某个不完全是 Windows 意义上的子系统的层(据我所知是 Cygwin)创建了文件或文件夹。同样WSL(适用于 Linux 的 Windows 子系统)在 Windows 10 上现在是另一个候选者。
  3. 不同的操作系统创建了它(例如,并行 Linux 启动)。
  4. 它是位于非 Windows 服务器上的网络共享上的文件。

最后两点也暗示了提到的补救措施之一:启动非 Windows Live CD 并删除文件。

这个问题实际上可以与旧的非 Unicode Win32 程序遇到来自多个代码页的文件名的情况进行比较。它经常无法“找到”其中一些,因为每个相应的 ANSI 代码页只能容纳 256 个字符,而 UTF-16(但不是其子集 UCS-2)理论上可以编码几乎无限数量的代码点(请阅读有关该主题的内容unicode.org维基百科)。

希望这有助于进一步理解潜在的问题。我不想把这个长答案编辑成其他答案,尽管它仅有的补充它们。没有这个答案,其他答案也完全有效。


脚注1:路径中的最大字符数不是绝对的,因为接近绝对最大值(32767 个字符)的路径可能会被对象管理器和文件系统过滤器或文件系统本身(例如重新解析点)扩展。

答案4

我遇到了完全相同的问题。

我创建了一个新的 Windows 管理员帐户,并且能够从那里登录并删除该文件夹。

相关内容