当编写一个大小接近8Gb的相当大的文件时,我对System.IO.FileStream有一个非常混乱的经历***。对FileStream.SetLength(LARGE_NUMBER)的调用突然失败并出现错误
由于文件系统限制,无法完成请求的操作
stacktrace是:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.SetLengthCore(Int64 value)
at System.IO.FileStream.SetLength(Int64 value)
at LiteDB.FileDiskService.WriteJournal(ICollection`1 pages, UInt32 lastPageID)
...
这是可重复的,并且相当令人费解,因为谷歌搜索没有明显的答案。
为了记录,LARGE_NUMBER SetLength被调用的大约是8,110,000,000 - 不小,但不是特别的。我以前在NTFS上看到过更大的文件。
***这是一个LiteDB数据库文件 - 我确实认识到我可能会延伸它的用途,但这不是问题的关键。
答案 0 :(得分:1)
虽然我不能说我已找到问题所在的确切解释,但我设法解决了问题并使我的程序继续扩展此文件。
我不能说这是否相关,但我注意到https://support.microsoft.com/en-us/help/967351/a-heavily-fragmented-file-in-an-ntfs-volume-may-not-grow-beyond-a-cert处的一行说了以下内容:
NTFS文件系统卷中严重碎片化的文件可能不会超出由用于描述分配的结构中的实现限制导致的特定大小。
由于我没有其他想法,我想我会尝试简单地制作一份文件,并希望副本最终不会像一个逐渐写入的文件一样碎片化很长一段时间的小增量。令人惊讶的是,这个工作,并且旧文件副本上的FileStream.SetLength(LARGE_NUMBER)再次开始工作。
有趣的是,在我复制之前,我尝试重命名旧的有问题的文件,我甚至无法做到这一点,得到一个Windows错误弹出窗口说文件系统限制相同的事情。