GetFreeDiskSpaceEx 如何返回（看似）错误的磁盘空间量？

Question

所以我在一个输出大图像（从 30MB 到 2GB+）的设备上工作。在我们开始创建这些映像之一之前，我们通过GetDiskFreeSpaceEx 检查是否有足够的磁盘空间。通常（在这种情况下）我们正在写入同一网络上的共享文件夹。磁盘空间上没有用户配额。

昨晚，为了准备演示，我们开始了试运行。在运行过程中，我们遇到了失败。我们需要327391776 字节，并被告知我们只有186580992 可用。 GetDiskFreeSpaceEx 的数字是：

用户可用空间：186580992

总可用空间：186580992

这些对应于lpFreeBytesAvailable 和lpTotalNumberOfFreeBytes 到GetDiskFreeSpaceAvailable 的两个（输出）参数中的QuadPart 变量。

此代码已使用多年，我从未见过假阴性。这是完整的功能：

long IsDiskSpaceAvailable( const char* inDirectory, 
                           const _int64& inRequestedSize, 
                           _int64& outUserFree, 
                           _int64& outTotalFree, 
                           _int64& outCalcRequest  )
{
    ULARGE_INTEGER  fba;
    ULARGE_INTEGER  tnb;
    ULARGE_INTEGER  tnfba;
    ULARGE_INTEGER  reqsize;
    string          dir;
    size_t          len;

    dir = inDirectory;
    len = strlen( inDirectory );

    outUserFree     = 0;
    outTotalFree    = 0;
    outCalcRequest  = 0;

    if( inDirectory[len-1] != '\\' )
        dir += "\\";
    
    // this is the value of inRequestSize that was passed in
    // inRequestedSize = 3273917760;
    if( GetDiskFreeSpaceEx( dir.c_str(), &fba, &tnb, &tnfba ) )
    {
        outUserFree         = fba.QuadPart;
        outTotalFree        = tnfba.QuadPart;

        // this is computed dynamically given a specific compression
        // type, but for simplicity I had hard-coded the value that was used
        float compressionRatio = 10.0;
        reqsize.QuadPart = (ULONGLONG) (inRequestedSize / compressionRatio);
        outCalcRequest   = reqsize.QuadPart;

        // this is what was triggered to cause the failure,
        // i.e., user free space was < the request size
        if( fba.QuadPart < reqsize.QuadPart )
            return( RetCode_OutOfSpace );
    }
    else
    {
        return( RetCode_Failure );
    }
    
    return( RetCode_OK );
}

因此，3273917760 的值被传递给函数，这是压缩前所需的磁盘空间总量。该函数将其除以10 的压缩比，得到所需的实际大小。

当我检查共享所在的磁盘时，它有大约 177GB 的可用空间，远远超过所报告的。再次开始测试后没有改变任何工作。

所以我的问题是；什么可能导致这样的事情？据我所知，这不是编程错误，而且正如我之前提到的，这段代码已经使用了很长时间，没有任何问题。

我检查了远程机器的事件日志，在发生故障的时候没有发现任何有趣的东西。我希望有人以前见过类似的东西，在此先感谢。

Answer 1

可能没有任何用处，但“奇怪”的是：

177GB ~= 186580992 * 1000。

这可能是由于代码中其他地方发生的堆栈损坏（因为您没有初始化局部变量）。

代码“inRequestedSize / compressionRatio”不必使用浮点数进行除法，而且由于您已经通过强制转换消除了“转换松散精度”警告，因此您实际上也可能遇到错误（但数字示例中给出的应该可以工作）。您可以简单地执行“inRequestedSize / 10”。

最后但并非最不重要的一点是，您没有说明代码在哪里运行。在移动设备上，GetDiskFreeSpaceEx 的文档指出：

启用移动加密后，此函数的报告行为会发生变化。每个加密文件至少有一个 4 KB 的相关开销页面。此函数在报告可用空间量时会考虑此开销。也就是说，如果一个 128 KB 的磁盘包含一个 60 KB 的文件，则此函数会报告 64 KB 可用，减去文件占用的空间及其相关开销。

虽然此函数会报告总可用空间，但在估计多个新文件是否适合剩余空间时，请记住加密文件的空间要求。包括启用移动加密时开销所需的空间量。每个文件至少需要额外的 4 KB。例如，一个 60 KB 的文件需要 64 KB，但两个 30 KB 的文件实际上需要 68 KB。