在 Windows XP 64 上，我下载了一个 1.2 GB 的文件，结果它变得碎片化了，如图所示。不幸的是，在从 Piriform Defraggler 拍摄快照之前，我对其他文件进行了碎片整理，因此您无法看到文件写入时的确切状态。但是，磁盘一直和现在一样空（使用了 25%），几乎没有碎片。
NTFS 使用什么块分配算法？它看起来像是随机的，或者可能将其放置在磁盘头实际所在的位置。
更新：
今天在写入 67 MiB 的新文件后发生了这种情况。它被分成 731 个片段，平均大小只有 95 KiB。该文件被用来填补一些空白，但不是全部，它也没有使用巨大的连续可用空间。很奇怪，不是吗？
更新2：
不同于电脑大师，我真的不认为 Opera 是罪魁祸首。我认为它（与 Google Chrome 相反）不会告诉 Windows 预期的大小，但是，在很多情况下这是不可能的，操作系统有责任以合理的方式处理它。下图显示了几天后我几乎没有在这个分区上做任何事情的情况 - TEMP 目录和我的所有数据（Windows 管理的除外）都位于其他地方。Windows 本身似乎不使用并以可怕的方式SetEndOfFile碎片化自己的文件（几个约 40 MB 的小文件有 600 个碎片）。NTFS 似乎不使用第一个可用扇区，因为在相当空的磁盘（使用率为 23%）的中间和末尾附近也有文件，因此确切的算法仍然未知。
答案1
如果我没记错的话，NTFS 文件系统会尝试将文件分配到连续的存储中。但是，只有当文件系统知道文件的大小时，它才能这样做。如果您打开一个文件并开始写入，它会写入适合该文件的“最佳”位置（通常是在磁盘的外侧）。但那个“最佳”位置可能不够大，无法容纳该文件。
如果应用程序告诉 NTFS 文件的实际大小（使用设置文件结束符（））时，NTFS 可以更好地为文件找到连续的空间（SetEndOfFile API 导致 NTFS 为整个文件分配存储空间）。
答案2
你的问题肯定出在 Opera 上。我刚刚查看了一个非常满且碎片化的驱动器上的一堆文件。使用 Chrome 下载的大文件都是连续的。
这表明 Chrome 在开始下载时就知道文件的大小，因此会告诉 NTFS 预期的文件大小。如果您这样做，NTFS 会尝试将文件放在单个碎片中，或者当没有足够大的碎片时，将其放入最大的可用碎片中。有趣的是，它总是按大小降序使用这些碎片，因此 Explorer 复制到碎片驱动器上的大文件可能会在整个驱动器上跳来跳去。
如果程序不知道文件大小，或者懒得告诉 NTFS，而是打开文件并开始写入顺序数据，那么 NTFS 的行为似乎与 FAT32 非常相似，它只是从第一个可用簇（或该会话中最后一个分配簇之后的第一个可用簇）开始，然后使用从那里开始的任何可用簇。例如，大约在同一时间，我要求 CCleaner 扫描注册表，导致它将其备份到一个大型 txt“.Reg”文件中。该文件从驱动器的开头附近开始，然后分散在 127 个不同的片段中。与使用 Explorer 复制或使用 Chrome 下载的文件不同，在我查看的每个文件中，簇都是按升序分配的。
为了进行这项研究，我使用了 Winhex（可从 Winhex.com 获得免费试用版）。查看目录条目时，右键单击文件名并选择“位置”、“列出簇”，以查看该文件使用的簇列表。