什么因素会导致Win32错误665（文件系统限制）？

我维护一个从数据记录器收集数据并将该数据追加到二进制文件末尾的应用程序。该系统的本质是该文件一次可以增长很大（> 4千兆字节）的小步骤。对我的应用程序的用户看到他的NTFS分区的情况下，尝试追加数据失败。由于调用fflush（）而导致错误报告。发生这种情况时，GetLastError（）的返回值是665（ERROR_FILE_SYSTEM_LIMITATION）。 MSDN给出了这种错误什么因素会导致Win32错误665（文件系统限制）？

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

一种对谷歌这个错误代码搜索提供了有关SQL服务器具有非常大的结果文件（几十千兆字节），但目前，我们的文件要小得多。该用户无法使文件增长到超过10 GB。当我们做一些操作（如复制文件）时，我们可以暂时纠正这种情况，这会迫使文件系统进行某种重写。不幸的是，我不确定发生了什么事情使我们摆在首位。在调用fflush（）时，NTFS文件系统中的哪些特定条件会导致此特定错误报告？

来源

2011-09-06 Jon Trauntvein

也许[这]（http://blogs.technet.com/b /mikelag/archive/2011/02/09/how-fragmentation-on-incorrectly-formatted-ntfs-volumes-affects-exchange.aspx）有所帮助。这是关于Exchange，但也许你可以在那里找到一些东西。 –

http://support.microsoft.com/default.aspx?scid=kb;EN-US;967351 –

这听起来像你已经达到了文件碎片的限制。换句话说，每次刷新都会创建一个新的文件扩展名（片段），并且文件系统很难找到一个位置来跟踪片段列表。这可以解释为什么复制文件有帮助 - 它会创建一个包含更少片段的新文件。

可能工作的另一件事是对文件进行碎片整理（使用Sysinternals的contig实用程序，您可能可以在使用它时这样做）。您也可以使用contig来告诉您文件有多少个分段。我猜这是一百万的数量级。

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

如果你是勇敢的（和你的进程具有管理员权限），你可以自己用几个API调用整理文件：http://msdn.microsoft.com/en-us/library/aa363911(v=VS.85).aspx

来源

2011-09-06 17:37:35 Gabe

我没有意识到contig实用程序，它似乎是一个有用的工具。不幸的是，它无法对文件进行碎片整理。错误代码是相同的（665）。显然，重叠群组无法整理碎片太多的文件。 –

@Jon：是的，我恐怕你得在它变大之前运行'contig' *。 'contig -a'对你的文件有什么看法？ – Gabe

contig -a报告该文件有77771个片段。我复制了该文件并重叠群，然后报告该文件有一个片段。报告的碎片数似乎是文件系统中一种奇怪的限制。是否有某种硬性限制或者是否存在某种间接性？ –

什么因素会导致Win32错误665（文件系统限制）？

回答

相关问题