我的笔记本电脑的系统是 Windows Vista。我无法删除该found.002文件夹。它是什么？我该如何删除它？
我试过了del found.002。但根本不起作用。
编辑：感谢答案，我已经能够删除文件夹found.002和found.003。但我无法删除found.004。第二个图中的字符在英语中表示“拒绝访问”。
答案1
您可以通过资源管理器删除文件夹，也可以从命令行删除： rd /s /q found.002或其他任何文件夹。
请记住，rd /s /q将在未经确认的情况下完全删除目录，因此请确保在运行它之前要删除该目录。
答案2
历史
在 MS-DOS 和 PC-DOS 时代，chkdsk实用程序在恢复丢失的文件（即文件分配表中仍有空间但未列在任何目录中的文件）时，会在根目录中为这些文件创建目录条目，名为FILE嗯嗯.CHK和DIR嗯嗯.CHK。当时，fsckUnices 上的程序则相反，将其发现的孤立文件放置在根目录下名为的子目录中lost+found。
这种chkdsk策略并不好，原因有很多，其中最重要的一点是，在 FAT12 和 FAT16 卷上，根目录的大小是固定的，不像其他目录那样是可变长度的。如果丢失的文件太多，最终会填满根目录。所以当 IBM 和 Microsoft 推出 HPFS（OS/2 版本 1.2）时，就做出了改变，因为提供 HPFS 支持需要对、、和等chkdsk工具进行全面改造。 chkdskformatsysrecover
因此，OS/2 版本的chkdsk实现就是为了执行该fsck操作。它在根目录中创建子目录，并将恢复文件的新目录条目放在那里。但它没有使用固定的子目录名称fsck。相反，它试图创建一个found.嗯嗯目录，其中嗯嗯开始于000并不断增加，直到它不与任何现有子目录冲突。该目录中将包含所有FILE嗯嗯.CHK和DIR嗯嗯.CHK文件。仍然有可能填满根目录（无论如何在 FAT12 和 FAT16 上 — HPFS 没有固定大小的根目录），只是它需要有人严重破坏文件系统并且从不将恢复的文件和目录从恢复目录中拉出来的病态场景。
（fsck使用固定的单个子目录，因为许多 Unix 文件系统格式都有固定大小的 inode 表。相比之下，HPFS 和 NTFS 没有固定大小的表来保存 f 节点和 MFT 条目，而 FAT 甚至没有有首先，不要担心这些事情。当有一个固定大小的表时，可能会遇到没有可用 i 节点作为新恢复子目录的情况，但有孤立的 i 节点需要恢复。为了 fsck避免这种死锁，要求系统管理员提前创建目录，以便正确操作lost+found，并且每次只使用同一个目录。当然，lost+found如果不存在，它会创建，但这为上述死锁的发生打开了大门。）
许多“DOS 命令详解” WWW 站点不会告诉您有关 的这些内容chkdsk，即使它在您和大多数人现在使用的操作系统上已经以这种方式工作了二十年。相反，它们仍会告诉您旧的 MS-DOS 是如何chkdsk工作的。OS/2 版本 1.2 于 1989 年问世。Windows NT 的第一个版本于 1993 年问世，它从 OS/2 1.x 继承了一些东西，包括 的这种行为chkdsk。与此同时，DOS 和 DOS+Windows 世界在接下来的十年里继续快乐地发展，没有注意到——或者从未纳入——这些chkdsk来自 20 世纪 80 年代后期的改进。DOS 和 DOS+Windows 世界，以及所有涌现出来告诉人们它们如何工作的书籍和 WWW 站点，实际上仍然停留在 1985 年。然而，DOS 和 DOS+Windows 世界终于走向了它应得的消亡，Windows NT 不是 DOS，也从来不是，并且chkdskWindows NT 中的命令在 20 世纪 80 年代末不再与 DOS 命令相同chkdsk。该命令的行为并不是那些错误地认为它是“DOS 命令”的人会告诉你的行为。
原理与运作
它之所以能如此运作，原因之一fsck是它是为一个操作系统设计的，而这个操作系统已经多用户在 1980 年代出现。在安全的多用户操作系统上，如果在磁盘崩溃后恢复文件意味着每个人都可以访问他们以前无法访问的文件，那么这是一个安全问题。您会发现，lost+found任何 Unix 或 Linux 系统上的 的标准权限都是 0700 ( rwx------)，所有者为root。只有超级用户才能访问目录的内容。因此，如果文件之前不在组可访问/世界可访问的目录中，则不会因为从文件系统损坏中恢复而突然变得可供人们访问。
chkdskWindows NT 上也面临同样的问题，这就是为什么你会发现found.嗯嗯NTFS 卷上的目录只能由管理员访问。（在 FAT 卷上，没有文件系统 ACL，因此无法通过这种方式确保安全。但是，原始位置上的文件并没有受到保护任何一个；所以这不是介绍安全漏洞。）这也是为什么您会发现 NTFS 卷上的回收站底层目录的结构与原先相同。删除文件不会使其他人突然可以访问这些文件，而这些人在原始目录中无法访问这些文件。
说到顶层的名字found.嗯嗯目录：
- 就其本质而言，恢复的孤立文件和目录在 FAT 卷上没有名称。名称应该在指向文件的目录条目中，但文件/目录没有指向它们的目录条目.这就是为什么
FILE嗯嗯.CHK和DIR嗯嗯.CHK使用名称。必须为文件和目录发明名称。 - 在 HPFS 卷上，可以恢复孤立文件的名称，因为它存储在 f 节点以及指向 f 节点的目录条目中。但您仍然会发现
FILE嗯嗯.CHK和DIR嗯嗯.CHK正在使用的名称。 - 在 NTFS 卷上，通常看不到以这种方式恢复的孤立文件，因为 MFT 条目包含文件/目录名称和最初包含目录的 MFT 条目编号。因此，恢复 NTFS 上丢失的文件和目录实际上可以将它们放回到丢失的目录中，并且通常（但并非总是）甚至不需要
found.嗯嗯目录。（当然，如果没有原始包含目录可以恢复来放置文件，它就会这样做。）这就是为什么很少看到found.嗯嗯与 FAT 卷相比，NTFS 卷上的目录。
当然，文件和目录的名称之内恢复的目录将保留，因为它们一开始并没有丢失。相反，它们是目录中的目录条目，而目录本身已经丢失。因此，一切以下ADIR嗯嗯.CHK顶层目录将保留其原始名称。
在 HPFS 卷上，丢失的文件/目录是没有目录条目指向的（已分配）f 节点。在 NTFS 卷上，丢失的文件/目录是没有目录条目指向的（已分配）MFT 条目。在这两种情况下，分配给文件/目录的整个空间都记录在 f 节点/MFT 条目中，并且与卷分配位图的任何冲突都会得到解决，以将空间分配给 f 节点/MFT 条目。在 FAT 上，情况有所不同。没有 f 节点、i 节点或 MFT 条目。查找丢失的文件/目录的唯一方法是在 FAT 中查找没有目录条目指向它们的簇链，并且 FAT是分配图以及。因此，无法检测出真正的丢失的文件/目录和文件/目录片段在卷分配图中没有被标记为空闲。因此，在 FAT 上，人们经常发现恢复的文件或目录部分的文件或目录。（这并不是说不可能在 HPFS 和 NTFS 上获取部分文件/目录。只是这种情况发生的必要条件要少得多，而且在 NTFS 上，通过元数据日志记录可以很大程度上完全避免这种情况。）
同样，在 HPFS 和 NTFS 上，可以根据 f-node/MFT 条目确定恢复的节点/条目是文件还是目录。f-node/MFT 条目中有一个标志表明它是什么。FAT 则不是这样。 最好我们可以运用启发式方法来查看集群的内容，猜测东西原本是什么。所以有时候，如果内容看起来正确，丢失的目录可以作为文件恢复，反之亦然。
最后说明一下：FAT 卷上有第三种类型的恢复文件：EA嗯嗯.CHK。这是 OS/2 1.x 的另一项创新，延续到 Windows NT。这些文件包含丢失的扩展属性. 扩展属性集保存在EA DATA. SFFAT 卷上的特殊容器文件 ( ) 中。如果没有目录条目指向特定的扩展属性集，则该 EA 集被视为丢失，并且要么作为EA嗯嗯.CHK文件或仅标记为可用空间。