XP$EXTEND目录下出现的奇怪文件

[jobsmo]

前几天用一个扫描ROOTKIT的软件扫描电脑,结果提示在C盘的$EXTEND目录下被ROOTKIT了,而且文件不能删除,马上用深山红叶光盘启动,浏览C盘,结果发现在C盘和其它盘的$EXTEND目录下多了个$RmMetadata的文件夹（D盘用的是FAT32格式，没有$EXTEND文件夹，其它分区都是NTFS）,占用了20MB的空间，里面有$TxfLog.blf、$Tops、$TxfLogContainer00000000000000000001、$TxfLogContainer00000000000000000002几个文件，那时候想都没想就把所有的$RmMetadata文件夹删除了。重启，噩梦降临了，先是蓝屏，进不了系统，格式化C盘后重装，进了系统后发现除了D盘外其它盘都不能访问了，打开提示无法访问，文件或者目录损坏且无法读取，查看属性，文件系统是RAW，已用空间和可用空间都是0字节，容量都是0字节，里面有上百G下回来的HDTV，丢失的话真是欲哭无泪，得想办法把数据找回来，首先想到用数据恢复软件把删除的文件恢复回来看看，用了FINAL DATA和Easy Recovery等数据恢复工具扫描，结果扫描失败，磁盘修复工具也没用，真当一筹莫展的时候用分区魔术师查看的分区显示是正常的，文件格式和空间占用情况和之前一样，有戏，用KNOPPIX LINUX光盘启动后发现可以正常浏览分区，里面的文件一个都没少，证明数据没有丢失，是硬盘的文件目录表发生了故障，导致系统不能浏览分区。问题找到了，怎样重建文件目录表这个问题很伤脑筋，突然想到，假如从分区中划分一部分容量出去，重新建立一个分区，然后再和之前的分区合并，这样不就可以重新建立文件目录表了？先用Pragon Partition Manager把其中一个分区分割出一部分容量，新建分区，再把两个合并，丢失的数据终于回来了。
找回数据后第一件事就是上网搜索问题发生的原因，可是在GOOGLE和百度的中文网页中都找不到和我有一样情况的报告，只在GOOGLE的英文网页上找到一些相关的资料，相关联接：http://forum.sysinternals.com/forum_posts.asp?TID=2214&PN=1 我之前装过VISTA的测试版，$RmMetadata会不会是VISTA添加进去的呢，我搜索了微软的知识库，找不到相关的资料，$RmMetadata究竟是什么？请各位高手赐教。

[就是just4]

怎么这么长呀，长的东西从来不仔细看，，

[hsc790621851]

请问楼主你是闲着蛋疼么。。。

请看下面文章，比较难读懂，好好读读，看到结尾你会懂的

WIN7\WINVISTA内核事务管理器

　　软件开发中最繁琐的一个方面就是处理错误条件。特别是在进行高级操作的过程中，应用程序完成了一个或多个导致文件系统或注册表更改的子任务。例如，应用程序的软件更新服务可能要进行几次注册表更新，替换应用程序的可执行文件之一，而在它尝试更新第二个可执行文件时被拒绝访问。如果服务不想将应用程序留在因此导致的不一致状态，就必须跟踪所有更改并为撤销它们做好准备。测试错误恢复代码很困难，并经常跳过，因此恢复代码中的错误会让努力徒劳无功。

　　为 Windows Vista 编写的应用程序通过使用 NTFS 中新的事务支持和使用内核事务管理器的注册表，不费吹灰之力即可获得自动错误恢复能力。当应用程序想进行许多相关更改时，可以创建分布式事务处理协调器 (DTC) 事务和 KTM 事务处理，或直接创建 KTM 处理，并将对文件和注册表项的修改与事务关联起来。如果所有的更改成功，应用程序会提交事务同时更改生效，但是在此之前任何时候，应用程序可以回滚事务，然后放弃更改。

　　其有利因素在于，其他应用程序在提交事务后才能看到事务中的更改，而在 Windows Vista 和即将问世的 Windows Server（代号名为“Longhorn”）中使用 DTC 的应用程序会通过 SQL Server、Microsoft Message Queue Server (MSMQ) 以及其他数据库协调其事务。因此，使用 KTM 事务的应用程序更新服务永远不会将应用程序留在不一致的状态。这就是 Windows Update 和系统还原使用事务的原因。

　　作为事务支持的核心，KTM 允许事务资源管理器（如 NTFS 和注册表）对应用程序所做的特定更改协调其更新。在 Windows Vista 中，NTFS 使用称为 TxF 的扩展来支持事务。注册表使用称为 TxR 的类似扩展。这些内核模式资源管理器与 KTM 一起协调事务状态，正如用户模式资源管理器使用 DTC 跨多用户模式资源管理器协调事务状态一样。第三方也可以使用 KTM 实施其自己的资源管理器。

　　TxF 和 TxR 都定义了一套新的文件系统和注册表 API（与现有的类似，只不过它们包含事务参数）。如果应用程序想在事务中创建文件，首先要使用 KTM 创建事务，然后将引起的事务处理传递给新文件创建 API。

TxF 和 TxR 都依赖在 Windows Server 2003 R2 中引入的公用日志文件系统或 CLFS (%SystemRoot%\System32\Clfs.sys) 的高速文件系统记录功能。TxR 和 TxF 使用 CLFS 永久性地存储提交事务之前的事务状态更改。这样可以让它们提供事务恢复并确保即使在断电时也可以恢复。除了 CLFS 日志，TxR 还创建了一组相关的日志文件，跟踪 %Systemroot%\System32\Config\Txr 中系统注册表文件的事务更改（如图 1 所示），同时还为每个用户注册表配置单元单独创建几组日志文件。TxF 在名为 \$Extend\$RmMetadata 的卷的隐藏目录中存储每个卷的事务数据。

[againoooooo]

这个……的确有点疼啊