我正在编写一个 32 位 C# 应用程序，它通过从 kernal32.dll FindFirstFile 获取文件信息来返回目录的总体大小。这已经胜过以常规方式枚举每个目录，并且我能够将资源使用保持在极低水平。

其工作原理的简要概述如下:

• 第 1 步 - 枚举根目录，获取所有子目录并使用 FindFirstFile 收集此目录中每个文件的大小信息。
• 第 2 步 - 生成子线程(最多 20 个)以针对子目录执行第 1 步
• 第 3 步 - 递归直到目录耗尽并且所有文件信息都已收集。

这可以在下面的代码示例中看到，其中 FileSystem.GetFiles 是我的类，它利用 kernal32 方法获取文件信息。

      private static void recurseDirectories(string directoryA, bool paramInitialPass)
    {
        try
        {
            string[] currentDirs;
            if (paramInitialPass)
            {
                currentDirs = new string[1];
                currentDirs[0] = rootDirectory;
            }
            else
                currentDirs = Directory.GetDirectories(directoryA);

            for (int i = 0; i < currentDirs.Length; i++)
            {

                string threadInfo = currentDirs[i];
                numThreadsQueued++;
                ThreadPool.QueueUserWorkItem(new WaitCallback(getDirectoryFileInformation), (object)threadInfo);
                while (numThreadsQueued - directoriesProcessed > 20)
                {
                    Thread.Sleep(30);
                }
                if (paramInitialPass)
                    recurseDirectories(directoryA, false);
                else
                    recurseDirectories(currentDirs[i], false);
            }
        }
        catch
        {

        }
        return;
    }


    private static void getDirectoryFileInformation(object paramDirectoryFilePathA)
    {
        try
        {
            string directoryPathA = (string)paramDirectoryFilePathA;
            List<FileData> filesDirectoryA = new List<FileData>();
            if (Directory.Exists(directoryPathA))
            {
                    filesDirectoryA = FileSystem.GetFiles(directoryPathA);
            }
            foreach(FileData file in filesDirectoryA)
            {
                Interlocked.Add(ref sizeOfFiles, file.Size);
                Interlocked.Increment(ref numberOfFiles);
            }               
        }
        catch (Exception e)
        {

        }
        finally
        {
            Interlocked.Increment(ref directoriesProcessed);
        }
    }

使用以下代码调用这两个方法:

 ThreadPool.SetMaxThreads(30, 500);
 Thread.CurrentThread.Priority = ThreadPriority.Normal;
 rootDirectory = share["Path"].ToString();
 recurseDirectories(share["Path"].ToString(), true);
 while (numThreadsQueued != directoriesProcessed)
 {
        Thread.Sleep(1000);
 }

此代码在枚举大多数目录时表现完美。我能够在大约 8 分钟内递归 3TB 文件共享以获取总文件大小和文件数量，同时将 cpu 保持在 3% 以下并使用 15MB 内存。

现在问题来了......

在获取小目录 (1-200 GB) 的大小时，我没有发现与 Windows 在查看目录属性时所说的有任何重大差异。但是，我注意到在获取大目录 (2-3TB) 的大小时存在一些主要差异。

例如:

假设我正在查看目录 D:\TestDir，它是 DFSR 复制到另一台服务器的。 Windows 表示此目录在磁盘上为 2,949,944,019,217 字节或 2,974,186,774,528 字节(分别为 2.68 TB 或 2.70 TB)。 我的程序显示此目录为 3,009,619,048,759 字节或 2.737 TB。 FSRM 表示同一目录上的配额设置有 2.71 TB 的使用量。

我知道差异部分是由于 Windows 不包括隐藏文件的大小，但是当我将目录中隐藏文件的总大小 (87GB) 添加到 Windows 值时，我得到 ~2.78 GB，这仍然不同于我的值(value)。任何人都可以阐明我造成这些尺寸差异的其他原因吗？另外，有谁知道 FSRM 如何确定配额使用情况？

最终我想用一个使用我的数据的监控系统替换 FSRM 配额，但如果我的数据与 Windows 所说的不一致，我可能会收到有关磁盘使用情况的误报。

最佳答案

经过一些深入测试后，这最终成为 kernal32.dll FindFirstFile 方法的错误:

[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
internal static extern SafeFindHandle FindFirstFile(string lpFileName, out WIN32_FIND_DATA lpFindFileData)

此函数返回一个类“WIN32_FIND_DATA”，其中包含有关特定文件的信息，包括名称、大小、上次修改时间等。我运行了一个测试，将此函数返回的大小与系统返回的大小进行比较。 IO.FileInfo 类，并在非常小的一组文件上发现了一些明显的差异。针对包含约 150 万个文件的文件共享运行此命令时，两个文件返回的大小明显不同，如下所示:

文件 1
大小根据FileInfo:18158717658字节
大小根据WIN32_FIND_DATA:978848478字节

文件 2
大小根据FileInfo:18211490304字节
大小根据WIN32_FIND_DATA:1031621124字节

在这两种情况下，大小差异几乎正好是 16 GB。

为了解决这个问题，我仍将使用 Kernal32.dll 函数来获取文件路径，但使用 FileInfo 来获取大小。这似乎在不影响性能的情况下产生了良好的结果。

关于c# - 应用程序之间的 Windows 目录大小差异，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14105049/