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


9

一个月前,我在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

它不会:

  • 删除
  • 打开
  • 移动

常规属性:

一般

安全属性:

安全

如何删除该文件?


好吧,现在运行它
Alex

做完了,但是没有工作……
Alex

1
应该不行。无法从DOS / Windows内部删除它是设计使然。因此,您可以通过这种方式解决此错误。
Hennes

Answers:


14

在(提升的)命令提示符下尝试以下操作:

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

确定aux.c已删除,但现在当我尝试删除该目录时显然正在使用src文件夹
Alex

里面什么都没藏?也许rd /s /q \\?\C:\cygwin\src会有所帮助。
卡兰2013年

打印输出“ src”正在使用中
亚历克斯

2
卡兰:哦,聪明。避免使用普通的文件系统名称空间。@Alex Yan:文件夹中没有打开cmd窗口?
Hennes

是的,除非文件夹或其中的某个文件被抓住,否则rd应该可以解决问题。关闭所有其他打开的Windows /应用程序,然后检查src的属性。显示的文件大小和数量是多少?
卡兰2013年

13

您遇到的问题是由于过时的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)。

[edit]在win7-x86 Ultimate上完成的测试:

创建一个简单的测试文件:

S:\>复制con foo.c
测试
^ Z
        已复制1个文件。

检查内容:

S:\>输入foo.c
测试

现在使用aux .c

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

似乎Windows的某些部分仍然向后兼容。


但此文件是aux.c
Alex

3
它仍然以aux开头,并且旧的文件名样式为“文件名”点“扩展名”。我只是copy con aux.c在win7上测试过,但失败了。(copy con test.c确实有效)。
Hennes

7

正如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设备命名空间之间的区别。

现在如何首先创建这样的文件?有几种可能性。

  1. 一个Win32程序使用\\?\X:路径名的前缀,以便将可用的路径长度从260个字符扩展到大约32767个字符(请参见脚注1!),首先创建了该文件,从而规避了Win32子系统的某些限制。
  2. 植根于不同子系统的程序。创建了以前的POSIX子系统(后来为Interix,现在为SUA),OS / 2子系统(已不复存在,但以前在NT 3.51上存在)或某个并非Windows意义上的子系统的层(据我所知Cygwin)文件或文件夹。同样,Windows 10上的WSL(Linux的Windows子系统)现在是另一个候选对象。
  3. 创建了另一个操作系统(例如,并行Linux引导)。
  4. 它是位于非Windows服务器上的网络共享上的文件。

最后两点也暗示了所提到的一种补救措施:引导非Windows live CD并删除文件。

该问题实际上可以与旧的非Unicode Win32程序面临来自多个代码页的文件名的情况相比。通常,它无法“找到”其中的一些,因为每个相应的ANSI代码页只能容纳256个字符,而从理论上讲,UTF-16(而不是其子集UCS-2)可以编码几乎无限数量的代码点(在unicode.orgWikipedia上阅读有关该主题的信息)。

希望这有助于更多地了解潜在问题。不想将此长答案编辑为其他答案之一,尽管它只是对它们的补充。没有这个答案,其他答案是完全有效的。


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


我喜欢增加的技术背景。
Hennes 2013年

0

我遇到了这个问题,感到非常沮丧,没有任何效果。然后,我使用了Linux Ubuntu CD。从CDROM引导,进入演示模式,访问有问题的文件所在的位置,然后将其删除。它像梦一样运作。


1
请注意,Windows无法删除文件的原因可能是因为Windows中不允许的字符已被放入Linux的文件名中。我很确定不是因为Linux不在乎。我请主持人批准删除一些文本,并保留可用的部分。
Mogget
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.