C++ 哪些因素会导致Win32错误665（文件系统限制）？

我维护一个从数据记录器收集数据并将数据附加到二进制文件末尾的应用程序。这个系统的本质是文件一次可以增长大（>4G字节）小步。在我的应用程序的许多用户中，有人在他的NTFS分区上看到追加数据的尝试失败的情况。调用fflush（）会报告此错误。发生这种情况时，GetLastError（）的返回值为665（错误\文件\系统\限制）。MSDN对此错误给出了以下说明

由于文件系统限制，无法完成请求的操作

---

在google上搜索此错误代码会得到与SQL server相关的结果，其中包含非常大的文件（数十GB），但目前，我们的文件要小得多。此用户无法使文件增长超过10 GB。我们可以在执行某些操作（如复制文件）时暂时纠正这种情况，强制在文件系统中进行某种重写。不幸的是，我不确定首先是什么让我们处于这种状况。NTFS文件系统中的哪些特定条件会导致在调用fflush（）时报告此特定错误？

这听起来像是文件碎片达到了限制。换句话说，每次刷新都会创建文件的一个新区段（片段），文件系统很难找到跟踪片段列表的位置。这就解释了为什么复制文件会有帮助——它会创建一个碎片更少的新文件

另一件可能会起作用的事情是对文件进行碎片整理（使用Sysinternals的实用程序，您可以在文件使用时进行碎片整理）。您还可以使用

contig

告诉您文件有多少个片段。我猜大概有一百万

如果您必须频繁刷新文件并且无法对其进行碎片整理，那么您可以做的就是首先创建相当大的文件（一次分配所有空间），然后写入文件的连续字节，而不是追加

---

如果您很勇敢（并且您的进程具有管理员权限），您可以通过几个API调用对文件进行碎片整理：

可能会有所帮助。它是关于交换的，但也许你可以在那里找到一些东西。我不知道contig实用程序，它似乎是一个有用的工具。不幸的是，它无法对文件进行碎片整理。错误代码相同（665）。显然，contig无法对碎片太多的文件进行碎片整理。@Jon:是的，恐怕你必须先运行

contig

，然后它才会变得那么大。

contig-a

对您的文件有何评论？contig-a报告该文件有77771个片段。我复制了这个文件，然后contig报告说这个文件有一个片段。报告的片段数量似乎是文件系统中的一种奇怪的限制。这里是否存在某种硬限制或某种间接方式？@Jon:Windows可以从预先设置预期的文件大小（

SetEndOfFile

）中获益匪浅。这是创建一个大文件并覆盖它的一个不太老套的版本。@mAlters:使用

SetEndOfFile

与创建一个大文件并覆盖它有什么不同？