NTFS设计目标和特性

1. NTFS设计目标

NTFS设计目标就包含作为一个企业级文件系统所需要的各种特性：

1. 在意外发生时，数据损失最小

2. 保护敏感数据不被非法访问

3. 使用廉价的“硬件冗余”来保护数据。

针对这些要求，NTFS有以下特性：

可恢复性

原子性事务（atomic transaction）

1. 要么全做

2. 要么全不做

物理实现：分解每个操作，而且对于关键的文件信息，NTFS使用了额外的存储区，所以如果磁盘上一个扇区坏了，NTFS仍然可以访问这个卷的关键文件系统数据。

安全性

直接源于windows的对象模型。文件和目录都是被保护的对象，可以避免遭受到没有授权用户的访问。

物理实现：NTFS的MFT表有一个元文件专门存储安全描述符

数据冗余与容错能力

通过Windows分层驱动模型（在第九章中介绍）来实现。卷管理器可以跨越几个卷进行数据镜像。

物理实现：RADI 1 -----RADI5

2. NTFS的高级特性

多数据流Multiple data streams ：

文件每个相关联的信息都是属性，每个属性就是一个流。每个文件有一个默认数据流。

物理实现：代码定义了属性类型及结构体。

在NTFS中，与一个文件相关联的每一个信息，包括其名称、所有者、时间戳、内容等待，都被实现为一个文件属性（NTFS对象属性，NTFS object atrribute）。

每个属性是由一个流（stream）构成的，也就说，由一个简单的字节序列构成。这种一般化的实现方式使得很容易为一个文件加入更多的属性（也就说说加入更多的流。）

因为一个文件的数据“只不过是该文件的一个属性”而已，而且，新的属性还能够被加入进来，所以，NTFS文件（和文件目录）可以包含多个数据流。

NFTS文件有一个默认的数据流，此默认的数据流没有名称。应用程序可以创建附加的、有名称的数据流，并且可以通过其名称来访问这些数据流。为了避免改变原来的Microsoft Windows I/O API函数（它们只带一个字符串作为文件名参数。），数据流的名称是通过在文件名的后面再加上一个冒号“：”来指定的。因为冒号是一个保留字符，所以，它可以用作文件名称和数据流名称直接的一个分隔符，如下面的例子所示：

myfile.dat:stream2

每一个流有一个单独的分配大小（这个值定义了有多少磁盘空间为它而保留）、实际大小（定义了调用者已经使用了多少字节），以及有效数据的长度（这个数据流已经多少被初始化了）。而且每个流也被赋予了一个单独的文件锁，利用这个锁可以锁住字节范围，已经运行并发访问。

在Windows中，一个使用多数据流的组件是Windows server随带的Apple Macintosh文件服务器支持，还有Windows Explorer也是使用多数据流的应用程序。当你在一个NTFS文件上右键点击并且选择属性的时候，结果对话框中的summary（摘要）标签页将会允许你讲一些信息（比如标题、主题、作者和关键字）和该文件关联起来。Windows Explorer将这些信息保存在该文件的另外一个流中，名为summary information。

其他的应用程序也可以使用多数据流特性。比如一个备份工具可以使用额外的数据流来保持有关备份文件、与备份相关的时间戳信息。或者，一个存档工具可以实现多即存储结构，其中，在某个特定日期以前的文件，或者一段时间以来尚未被访问过的文件都被转移到磁带上。该工具可以把这样的文件拷贝到磁带上，并且将文件的默认数据流设置为0，再加入一个数据流来指定该文件存储在磁带上的名称和位置。

实验：查看数据流，使用echo和more命令，这两者支持命名数据流。

如果执行一次列目录的命令，test的文件大小并不反映出额外数据流中存储的数据，因为NTFS对于文件查询操作，只返回未命名数据流的大小，列目录命令也不例外。

还可以利用streams工具来确定，在你的系统上哪些文件和目录具有额外的数据流。

基于Unicode的名称Unicode-based names ：

NTFS使用unicode字符来储存文件、目录、卷名。文件名最长255个字符。Unicode是一种16位的字符编码方案，它允许世界上每一种主要语言的每一个字符都可以被唯一表示。

路径中的每个目录和文件名可以长达255个字符，可以包含Unicode字符、内嵌的空格和多个句点号。

物理实现：实际文件名最长253个字符。？

通用的索引设施General indexing facility：

可以对文件属性进行索引，使用统一的安全描述符。

NTFS的总体结构是高度结构化的，从而允许对一个磁盘卷上的文件属性进行索引。这个特性使得文件系统可以高效的定位到符合某种标准的文件，例如特定目录中的所有文件。FAT文件系统对文件名编了索引，但是并不对它们进行排序，因而使得在大的目录中查找文件非常慢。

NTFS的几个特性用到了通用的所以机制，包括统一的安全描述符。在一个卷上，文件和目录的安全描述符被保存在单个内部流中，因而可以去除重复的安全描述符，并且它使用NTFS定义的内部安全标识符进行索引。在后面的“NTFS在磁盘上的结构”一节中描述了这些特性使用索引机制的做法。

动态坏簇映射Dynamic bad-cluster remapping：

显式地让程序知道坏簇并不使用

物理实现：MFT表有一个元文件专门记录坏簇

一般而言，如果一个程序试图从一个坏磁盘扇区中读取数据，则读操作会失败，这个已经被分配的簇中的数据会变得不可访问。但是，如果这个磁盘被格式化为一个容错的NFTS卷，则Windows的容错驱动程序会动态的获得一份原本存储在此坏扇区中的数据的好的拷贝，然后发送一个警告，告诉NTFS这个扇区已经坏了。于是NTFS分配一个新的簇，替换掉扇区所在的簇，然后把数据拷贝到新的簇中。它对于坏的簇做上标记，以后不再使用这个簇。

这种数据恢复和动态的坏簇重新映射的机制，对于文件服务器和容错系统，或者对于不能承受数据丢失的任何应用程序来说，都是一种特别有用的特性。当一个扇区变坏的时候，这个管理卷还没有被加载，那么NTFS依然替换掉坏簇，不再使用这个坏簇，但是不能恢复坏簇上原来的数据。

硬链接（Hard links）

硬链接可以让多个路径指向同一个文件（不支持硬链接目录）。如果创建了一个硬链接指向一个已有的文件，这两个路径会指向同一个地址。任何一个路径都可以来改变这个文件。

进程可以利用Windows的CreateHardLink函数或者POSIX ln函数来创建硬链接。

软链接和交接Symbolic (soft) links and junctions ：

多个路径指向同一个文件。

与硬链接不同，符号链接是动态解释的字符串，可以是相对的或绝对路径，指的是任何存储设备上的位置，包括不同本地卷上的位置，甚至是不同系统上的共享。这意味着符号链接实际上不会增加原始文件的引用计数，因此删除原始文件将导致数据丢失，并且指向不存在的文件的符号链接将被丢弃。最后，不同于硬链接，符号链接可以指向目录，而不仅仅是文件，这给它们带来了额外的优势。

软链接的好处就是可以让一个目录或文件有多个入口但保持单一物理位置，方便应用和管理。

交接：

重定向，把一个文件和路径名重定向到另一个目录上。

物理实现：在MFT表有一个元文件专门记录重解析点。这个特性使得NTFS可以用一个目录名表示另一个物理卷。

Windows没有包含任何可以用来创建交接的工具，但是可以利用www.sysinternals.com的junction工具（网站上包含了其源代码），或者Windows资源箱里的工具Linked来创建一个交接。

例如，如果路径C:\Drivers程序是一个目录符号链接，它重定向到%StaseRoo%%\Stuls32 \Drivers，一个应用程序读取C:\Trave\NTFS.S实际上读取%StaseRooS%\Stsystem \Drivers\NTFS.Sys.

交接junctions是的一种有效方法，将目录树深处的目录提升到更方便的深度，而同时不破坏原来目录树的结构或内容。刚才引用的示例将Drivers目录升至卷的根目录，当通过交接junctions访问Ntfs.sys时，将NTFS.S的目录深度从三级降低到1级。你不能使用交接机制来连接到远程的目录，你只能连接到本地卷的目录中。

你可以把交接junctions的工作方式看作快捷方式一样，除了它们实际上是在文件系统上实现的，而不是由Windows资源管理器管理的.LNK文件。就像硬链接一样，交接junctions可以用MKLink实用工具（没有/h选项）或通过CytSysMyBrimLink API创建。

mklink是windows系统下创建符号链接和硬链接的命令工具，它是一个很好的解决文件系统问题的工具。使用它需要管理员权限。

首先，先来介绍下mklink这个命令，可以看下下面的截图：

mklink

创建符号链接。

MKLINK [[/D] | [/H] | [/J]] Link Target

/D      创建目录符号链接。默认为文件

符号链接。

/H      创建硬链接而非符号链接。

/J      创建目录联接。

Link    指定新的符号链接名称。

Target  指定新链接引用的路径

(相对或绝对)。

说明也已经很详细了，我们直接看下面例子吧。

下面的图片向我们展示了在windows系统中创建符号链接，硬链接和快捷方式有什么不同。

符号链接（Symbolic link）

执行命令 mklink link_name target_name

创建链接后的图标和快捷方式很像, 都有一个箭头的标志

在系统中不占用空间

在文件系统中不是一个单独的文件

在操作系统层解析（！？）

如果源文件被删除了，链接就没用了

移除源文件不会影响符号链接

移除链接文件也不会影响源文件

win10_x64_build10565上测试不可以右键修改图标和设置管理员运行

文件大小为0字节和不占用空间

文件属性的创建时间和修改时间都是软链接创建和修改时的时间

文件类型是.SYMLINK

可以在cmd下运行软链接(假如链接的是程序, 且运行命令是XXX即可)(win10_x64_build10565上测试通过)

硬链接（Hard link）

执行命令 mklink /H link_name target_name

在系统中占用的空间与源文件相同，但在系统中引用的是相同的对象（不是拷贝）

在操作系统层解析（！？）

图标和创建快捷方式的图标不同(没有快捷方式的小箭头)

移除源文件不会影响硬链接

移除硬链接不会影响源文件

如果源文件被删除，它的内容依然通过硬链接存在

硬链接文件的任何更改都会影响到源文件

文件大小, 占用空间, 创建和修改时间跟原原文件一样

可以在cmd下运行硬连接(假如链接的是程序)

快捷方式（Shortcut）

在选择的源文件上鼠标右键，通过下拉菜单创建

快捷方式在系统中跟源文件是完全分离的

只有那些懂得快捷方式的程序知道它们

如果源文件删除，链接就没用了

移除源文件不会移除快捷方式

移除快捷方式不会影响到源文件

可以右键更改图标或者设置管理员运行

文件属性的创建时间和修改时间都是快捷方式创建和修改时的时间

文件大小仅有几百字节, 跟原文件大小无关

文件类型是.lnk

可以在cmd下运行快捷方式(假如链接的是程序, 且运行命令是XXX.LNK)(win10_x64_build10565上测试通过)

压缩文件和稀疏文件Compression and sparse files：

NTFS支持文件数据的压缩功能。因为NTFS透明的执行压缩和解压缩过程，所以，应用程序不需要任何修改，就能够利用这个特性。目录也可以被压缩，这意味着，该目录中随后创建的任何文件都是经过压缩的。

应用程序压缩和解压缩的做法是，将 FSCTL_SET_COMPRESSION文件系统控制代码传递给DeviceIoControl。他们可以通过FSCTL_GET_COMPRESSION文件系统控制代码来查询一个文件或者目录的压缩状态。如果一个文件或者目录是压缩的，则它的属性中设置了FILE_ATTRIBUTE_COMPRESSED标志，所以可以通过GetFileAttributes来确定一个文件或者目录的压缩状态。

第二类压缩文件被称为稀疏文件。如果一个文件被标记为稀疏的，则NTFS并不为“该文件中被应用程序指定为空的部分”分配磁盘卷空间。当一个应用程序从一个稀疏文件的空区域读取数据的时候，NTFS返回以0填充的缓冲区。对于实现“循环缓冲区方式的日志（circular-buffer logging）”的客户/服务器应用程序来说，这种压缩类型会非常有用。在这种应用程序中，服务器将信息记录到一个文件中，而客户异步地从文件中读取信息。因为服务器写入的信息在客户度过以后，就不再需要，所以不需要将这些信息继续保存在文件中。通过将这样的文件做成一个稀疏文件，客户可以指定它读过的文件部分变成空，从而释放相应的卷空间。服务器可以继续在文件后面追加新的信息，不需要担心这个文件会一直增长从而消耗掉该卷上所有的可用空间。

和压缩文件一样，NTFS透明的管理稀疏文件。应用程序只需要将FSCTL_SET_SPARSE文件系统控制代码传递给DeviceIoControl，就可以指定一个文件的稀疏状态。要想设置文件中的一段范围为空的，应用程序可以使用FSCTL_SET_ZERO_DATA代码；应用程序还可以利用FSCTL_QUERY_ ALLOCATED_RANGES控制代码来询问NTFS，以获得一份关于“文件中哪些部分是稀疏的”的描述。稀疏文件的一个应用就是接下来要介绍的NTFS变化日志。

变化日志Change logging：

许多类型的应用程序需要监视一个卷中文件和目录的变化。例如，自动备份程序可以先执行一个初始的完全备份，然后基于文件更改进行增量备份。很显然，一个应用程序监视卷的变化的典型方法是扫描卷，记录文件和目录的状态，以及在随后的扫描检测后比对差异。然而，这个过程会对系统性能产生不利影响，特别是在成千上万或上万个文件的计算机上，系统性能会下降很多。

另一种方法是应用程序通过使用FiFixStReNeNoTeCudio或RerecDirectyReSeWWindows函数注册目录通知。作为输入参数，应用程序指定要监视的目录的名称，并且每当目录的内容发生更改时，函数就会返回。虽然这种方法比扫描卷更有效，但它要求应用程序始终在运行。使用这些函数还需要一个应用程序来扫描目录，因为FiffFistToSeNooToice并没有表明目录中的什么东西发生了变化，-只是通知某些东西发生了变化。应用程序可以将缓冲区传递给ReadDirectoryChangeW，其中FSD填充了更改记录。但是，如果缓冲区溢出，则应用程序必须准备好扫描目录。

NTFS提供了第三种方法，可以克服前两个缺点的：应用程序可以通过使用 FSCTL_ CREATE_ USN_JOURNAL日志文件系统控制代码（UN是更新序列号）来配置NTFS变化日志设施，让NTFS把有关文件和目录变化的信息记录到一个称为变化日志（change journal）的内部文件中。变化日志（change journal）通常大，足以保证应用程序有机会处理更改而不丢失任何更改。应用程序使用 FSCTL_QUERY_USN_JOURNAL 文件系统控制代码从变化日志中读取记录，还可以指定“直到有了新纪录以后DeviceIoControl函数才完成”。

针对每个用户的卷配额Per-user volume quotas :

为每个用户提供相应的配额管理

物理实现：MFT表元文件专门记录相关信息

系统管理员经常需要跟踪或限制共享存储卷上的用户磁盘空间使用，因此NTFS包括配额管理支持。NTFS的配额管理支持允许为每个用户指定相应的配额限制，这对于“跟踪使用量”和“用户什么时候达到警告和限制阈值时的使用”是有用的。NTFS可以被配置为如果用户超过其警告限制，则将事件的发生日志记录到系统事件日志。

类似地，如果用户尝试使用更多的卷存储，超出了其配额限制允许，NTFS可以将事件记录到系统事件日志指示其违反配额，并且会导致应用程序文件I/O失败，错误代码即“磁盘满”。

NTFS依靠文件和目录的创建者用户的用户安全ID（SID）来标记文件和目录，从而跟踪用户的卷使用。一个用户拥有的文件和目录的逻辑大小被计算在用户管理员定义的配额限制内。

因此，用户不能通过创建大于配额允许的空稀疏文件来绕过他或她的配额限制，然后用非零数据填充文件。

类似地，虽然50-KB文件可能压缩到10 KB，但使用50 KB的配额计费。

默认情况下，卷没有启用配额跟踪。您需要使用图12- 20所示的“卷属性”对话框的配额选项卡来启用配额，指定默认警告和限制阈值，并配置当用户达到警告或限制阈值时发生的NTFS行为。您可以从这个对话框启动Quto Entries工具，使管理员能够为每个用户指定不同的限制和行为。如果应用程序希望与NTFS配额管理组件打交道，可使用COM配额接口，包括 IDiskQuotaControl, IDiskQuotaUser, and IDiskQuotaEvents。

链接跟踪Link tracking :

外壳shell快捷方式允许用户将文件放在它们的外壳shell命名空间（例如在桌面上），这些文件实际上又链接到位于文件系统命名空间中的其他文件上。Windows开始菜单广泛使用外壳shell快捷方式。类似地，对象链接和嵌入（OLE object linking and embedding）链接允许一个应用程序的文档透明地嵌入到其他应用程序的文档中。微软Office套件的产品，包括PowerPoint、Excel和Word，使用OLE链接。

虽然shell和OLE链接提供了一种简单的方法来连接文件和shell命名空间，但是如果用户移动shell或OLE链接的源（链接源是链接点的文件或目录），那么它们很难管理。Windows中的NTFS包括对被称为分布式链接跟踪的服务应用程序的支持，该服务在链接目标移动时保持外壳和OLE链接的完整性。使用NTFS链路跟踪支持，如果位于NTFS卷上的链接目标移动到始发卷域中的任何其他NTFS卷，则链接跟踪服务可以透明地跟随移动并更新链接以反映该变化。

NTFS link-tracking support is based on an optional file attribute known as an object ID. An application can assign an object ID to a file by using the FSCTL_CREATE_OR_GET_OBJECT_ID (which assigns an ID if one isn’t already assigned) and FSCTL_SET_OBJECT_ID file system control codes. Object IDs are queried with the FSCTL_CREATE_OR_GET_OBJECT_ID and FSCTL_GET_OBJECT_ID file system control codes. The FSCTL_DELETE_OBJECT_ID file system control code lets applications delete object IDs from files.

NTFS链接跟踪支持是基于一个被称为对象的可选文件属性（对象ID）上的。应用程序可以通过使用FSCTL_CREATE_OR_GET_OBJECT_ID（如果还没有分配一个ID，则分配一个ID）和 FSCTL_SET_OBJECT_ID 文件系统控制代码，将一个对象ID分配给一个文件。对象ID用FSCTL_CREATE_OR_GET_OBJECT_ID和FSCTL_GET_OBJECT_ID文件系统控制代码进行查询。FSCTL_DELETE_OBJECT_ID文件系统控制代码允许应用程序从文件中删除对象ID。

加密Encryption:

企业用户通常在他们的计算机上存储敏感信息。虽然存储在公司服务器上的数据通常通过适当的网络安全设置和物理访问控制来安全地保护，但是当笔记本电脑丢失或被盗时，存储在笔记本电脑上的数据可以被泄露出去。这种情况下NTFS文件许可机制无法提供保护，因为NTFS卷可以通过使用NTFS文件阅读软件来完全访问，而不需要Windows运行的软件。此外，当使用另一个Windows系统上从管理员帐户来访问这些文件的时候，NTFS文件许可机制也无能为力。以前的章节曾经说过管理员帐户具有获取所有权和备份特权，这两种权限都允许它通过重写对象的安全设置来访问任何受到保护的对象。

NTFS包括一个称为加密文件系统（EFS     Encrypting File System）的设施，用户可以使用它来加密敏感数据。EFS的操作（如文件压缩的操作一样）对应用程序是完全透明的，这意味着当运行 一个应用程序读取文件数据的，如果它是在一个有权查看该文件数据的用户账户下运行的，则这些文件数据会被自动解密；当授权应用程序改变文件数据时候，文件数据被自动加密。

备注：NFTS不允许系统捐的根目录或者\windows目录中的文件被加密，因为这些目录中的许多文件对于引导过程是必需的，而在引导过程中EFS还没有被激活。

EFS依赖于Windows提供的，用户模式下的密码学服务，它是由一个内核模式组件和一些用户模式DLL组成的，其中内核模式组件和NTFS紧密的集成在一起，而用户模式DLL负责跟本地安全权威子系统（LSASS Local Security Authority Subsystem ）和密码学DLL进行通信。

POSIX支持：

1. 大小写敏感

2. 穿越目录的许可

3. “文件改变时间”时间戳

4. 硬链接

碎片整理Defragmentation：

Even though NTFS makes efforts to keep files contiguous when allocating blocks to extend a file, a volume’s files can still become fragmented over time, especially if the file is extended multiple times or when there is limited free space. A file is fragmented if its data occupies discontiguous clusters. For example, Figure 12-21 shows a fragmented file consisting of five fragments. However, like most file systems (including versions of FAT on Windows), NTFS makes no special efforts to keep files contiguous (this is handled by the built-in defragmenter), other than to reserve a region of disk space known as the master file table (MFT) zone for the MFT. (NTFS lets other files allocate from the MFT zone when volume free space runs low.) Keeping an area free for the MFT can help it stay contiguous, but it, too, can become fragmented. (See the section “Master File Table” later in this chapter for more information on MFTs.)

即使NTFS在分配块以扩展文件时努力保持文件连续，但是卷的文件仍然会随着时间的推移而变得碎片化，特别是当文件被多次扩展或者当有有限的空闲空间时。如果一个文件的数据数据占据不连续的簇，则认为文件被碎片化。例如，图12—21显示了一个由五个片段组成的碎片文件。然而，与大多数文件系统（包括Windows上的FAT版本）一样，NTFS没有特别的努力来保持文件连续（这是由内置碎片整理器处理的），除了为MFT保留一个被称为主文件表（MFT）区域的磁盘空间区域。（当卷释放空间变得很慢时候，NTFS允许其他文件在MFT区域分配）。保持MFT的空闲区域可以帮助它保持连续，但是它也会变得碎片化。（请参阅本章后面的“主文件表”一节，了解更多关于MFTS的信息）。

To facilitate the development of third-party disk defragmentation tools, Windows includes a defragmentation API that such tools can use to move file data so that files occupy contiguous clusters. The API consists of file system controls that let applications obtain a map of a volume’s free and in-use clusters (FSCTL_GET_VOLUME_BITMAP), obtain a map of a file’s cluster usage (FSCTL_GET_ RETRIEVAL_POINTERS), and move a file (FSCTL_MOVE_FILE). Windows includes a built-in defragmentation tool that is accessible by using the Disk Defragmenter utility (%SystemRoot%\System32\Dfrgui.exe), shown in Figure 12-22, as well as a commandline interface, %SystemRoot%\System32\Defrag.exe, that you can run interactively or schedule but that does not produce detailed reports or offer control—such as excluding files or directories—over the defragmentation process.

为了支持第三方开发磁盘碎片整理工具，Windows包含了一个碎片整理API。这类工具可以利用这个API来移动文件数据，从而是文件占据连续的簇。这个API是由一些文件系统控制代码构成的，这些文件系统控制代码运行应用程序得到一个卷的空闲和被使用的簇的地图（FSCTL_GET_VOLUME_BITMAP），得到一个文件簇使用的地图（FSCTL_GET_ RETRIEVAL_POINTERS），和移动一个文件 (FSCTL_MOVE_FILE)。

Windows包含一个内置的碎片整理工具，通过使用Disk Defragmenter工具可以访问到(%SystemRoot%\System32\Dfrgui.exe)。

C:\Windows\System32 和开始菜单都可以打开这个工具。

The only limitation imposed by the defragmentation implementation in NTFS is that paging files and NTFS log files cannot be defragmented.

只读支持 和动态分区Read-only support and dynamic partitioning：

The NTFS driver allows users to dynamically resize any partition, including the system partition, either shrinking or expanding it (if enough space is available). Expanding a partition is easy if enough space exists on the disk and is performed through the FSCTL_EXPAND_VOLUME file system control code. Shrinking a partition is a more complicated process, because it requires moving any file system data that is currently in the area to be thrown away to the region that will still remain after the shrinking process (a mechanism similar to defragmentation). Shrinking is implemented by two components: the shrinking engine and the file system driver.

NTFS驱动程序允许用户动态调整任何分区，包括系统分区，或者缩小或扩展系统分区（如果有足够的空间可用）。如果磁盘上存在足够的空间，并且通过 FSCTL_EXPAND_VOLUME 卷文件系统控制代码执行分区，扩展分区是很容易的。收缩分区是一个更复杂的过程，因为它需要将当前要扔掉的区域中的任何文件系统数据移动到收缩过程之后仍将保留的区域（类似于碎片整理的机制）。收缩是由两个组件实现的：收缩引擎和文件系统驱动程序。

The shrinking engine is implemented in user mode. It communicates with NTFS to determine the maximum number of reclaimable bytes—that is, how much data can be moved from the region that will be resized into the region that will remain. The shrinking engine uses the standard defragmentation mechanism shown earlier, which doesn’t support relocating page file fragments that are in use or any other files that have been marked as unmovable with the FSCTL_MARK_HANDLE file system control code (like the hibernation file). The master file table backup ($MftMirr), the NTFS metadata transaction log ($LogFile), and the volume label file ($Volume) cannot be moved, which limits the minimum size of the shrunk volume and causes wasted space.

收缩引擎是在用户模式下实现的。它与NTFS通信以确定可恢复字节的最大数量，即，可以从将被调整到将保留的区域中的区域移动多少数据。

收缩引擎使用前面所示的标准碎片整理机制，它不支持重新定位正在使用的页文件碎片或任何其他被FSCTL_MARK_HANDLE文件系统控制代码标记为不可移动的文件（如休眠文件）。

主文件表备份（$MFtmir）、NTFS元数据事务日志（$Logfile）和卷标签文件（$卷）不能移动，这限制了缩小卷的最小大小，并导致浪费空间。

The file system driver shrinking code is responsible for ensuring that the volume remains in a consistent state throughout the shrinking process. To do so, it exposes an interface that uses three requests that describe the current operation, which are sent through the FSCTL_SHRINK_VOLUME control code: 

■ The ShrinkPrepare request, which must be issued before any other operation. This request takes the desired size of the new volume in sectors and is used so that the file system can block further allocations outside the new volume boundary. The ShrinkPrepare request doesn’t verify whether the volume can actually be shrunk by the specified amount, but it does ensure that the amount is numerically valid and that there aren’t any other shrinking operations ongoing. Note that after a prepare operation, the file handle to the volume becomes associated with the shrink request. If the file handle is closed, the operation is assumed to be aborted. 

■ The ShrinkCommit request, which the shrinking engine issues after a ShrinkPrepare request. In this state, the file system attempts the removal of the requested number of clusters in the most recent prepare request. (If multiple prepare requests have been sent with different sizes, the last one is the determining one.) The ShrinkCommit request assumes that the shrinking engine has completed and will fail if any allocated blocks remain in the area to be shrunk. 

■ The ShrinkAbort request, which can be issued by the shrinking engine or caused by events such as the closure of the file handle to the volume. This request undoes the ShrinkCommit operation by returning the partition to its original size and allows new allocations outside the shrunk region to occur again. However, defragmentation changes made by the shrinking engine remain.

文件系统驱动程序收缩代码负责确保卷在收缩过程中保持一致状态。为此，它公开了一个接口，该接口使用三个描述当前操作的请求，这些请求是通过 FSCTL_SHRINK_VOLUME卷控制代码发送的：

“ShrinkPrepare 请求”，它必须在任何其他操作之前发出。这个请求占用扇区中新卷的期望大小，得到这个暑假文件系统可以阻止新的卷边界之外的进一步分配。ShrinkPrepare 请求不验证卷是否可以按指定的数量收缩，但它确实确保了数值是有效的，并且没有任何其他收缩操作正在进行。注意，在准备操作之后，卷的文件句柄与收缩请求关联。如果文件句柄已关闭，则假定操作被中止。

ShrinkCommit请求，收缩引擎在ShrinkPrepare请求之后发出请求。在这种状态下，文件系统尝试在最近的准备请求中移除所请求的簇数。（如果多个准备请求被发送到不同的大小，最后一个请求是确定的。）ShrinkCommit请求假定收缩引擎已经完成并且如果分配的块留在待缩小的区域中，则将失败。“收缩中止请求”，它可以由收缩引擎发出，也可以由诸如文件句柄关闭到卷的事件引起。此请求通过将分区返回到其原始大小来取消收缩提交操作，并允许重新收缩区域之外的新分配再次发生。然而，收缩引擎所做的碎片整理更改仍然存在。

“ShrinkAbort请求”，它可以由收缩引擎发出，也可以由诸如文件句柄关闭到卷的事件引起。此请求通过将分区返回到其原始大小来取消收缩提交操作，并允许重新收缩区域之外的新分配再次发生。然而，收缩引擎所做的碎片整理更改仍然存在。