c++ - GetFreeDiskSpaceEx 如何返回(看似)错误的磁盘空间量？

Question

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

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

User free space available: 186580992

Total free space available: 186580992

那些对应于 GetDiskFreeSpaceAvailable 的两个(输出)参数 lpFreeBytesAvailable 和 lpTotalNumberOfFreeBytes 中的 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”不必使用 float 进行除法，并且由于您已经通过强制转换消除了“转换松散精度”警告，您实际上也可能遇到错误(但数字示例中给出的应该有效)。您可以简单地执行“inRequestedSize/10”。

最后但同样重要的是，您没有说明代码在何处运行。在移动设备上，GetDiskFreeSpaceEx 的文档指出:

When Mobile Encryption is enabled, the reporting behavior of this function changes. Each encrypted file has at least one 4-KB page of overhead associated. This function takes this overhead into account when it reports the amount pf space available. That is, if a 128-KB disk contains a single 60-KB file, this function reports that 64 KB is available, subtracting the space occupied by both the file and its associated overhead.

Although this function reports the total available space, keep the space requirement for encrypted files in mind when estimating whether multiple new files will fit into the remaining space. Include the amount of space required for overhead when Mobile Encryption is enabled. Each file requires at least an additional 4 KB. For example, a single 60-KB file requires 64 KB, but two 30-KB files actually require 68 KB.