是否有可以存储在一个文件夹中的文件/文件夹的限制？

我们正在开发一个应用程序，针对从Windows XP SP 3到Windows 8的所有操作系统。用户有可能触发一些导致在硬盘上存储文件的操作。目前，我们正在为每个操作创build用户在特定目标文件夹中执行具有唯一名称的文件夹。

当前结构如下所示：

MyTargetFolder | |-- 0f8fad5b-d9cb-469f-a165-70867728950e | |--- SomeFile.txt | |--- AnotherFile.txt | |-- 7c9e6679-7425-40de-944b-e07fc1f90ae7 | |--- SomeFile.txt | |--- AnotherFile.txt . .

我想知道，如果有一个特定的最大数量的文件夹，可以存储在另一个文件夹 – 也许依赖于操作系统，也许依赖于文件系统（FAT32，NTFS，…？）。

如果有一个限制 – 这是什么？
如果一个文件夹没有限制 – 整个驱动器上的文件夹总数是否有限制？
当我尝试从我的C＃应用程序使用Directory.CreateDirectory创build一个文件夹，并已达到最大数量的文件夹会发生什么情况？
关于性能/索引 – 是否更快，将我们的结构和组文件夹更改为文件夹？

像这样的东西：

 MyTargetFolder | |-- AllFoldersStartingWith0 | | | |-- 0f8fad5b-d9cb-469f-a165-70867728950e | |--- SomeFile.txt | |--- AnotherFile.txt | |-- AllFoldersStartingWith7 | | | |-- 7c9e6679-7425-40de-944b-e07fc1f90ae7 | |--- SomeFile.txt | |--- AnotherFile.txt . .

（注意：当然，我们生产的文件夹超过了2个，因为用户执行的每个操作都会创build一个文件夹，而我们将GUID作为文件夹名称。）

每个Windows版本都有自己的限制，可存储在特定文件夹中的项目数[文件+文件夹]数量。尽管这个限制随着x64位系统的增加而增加，但是与原始性能相比，这个数字本身已经不再是问题了。随着特定文件夹中的[文件或文件夹]数量的增加，Windows似乎变得非常缓慢。您肯定需要考虑（或重新考虑）访问这些文件的策略。

如果直接进入NT内核API，10m项目目录执行得非常好，并且有32767个字符的路径限制不是260.您也不需要将您的文件名存储为GUID，因为NTFS将直接存储您的文件并将其索引为GUID即在记事本中打开一个路径，你只需输入卷GUID和文件GUID，它“只是工作”。唯一的不足之处是你不能选择我相信的NTFS为你分配的GUID。有关直接GUID功能的更多信息，请参阅http://blogs.msdn.com/b/oldnewthing/archive/2011/02/28/10134679.aspx 。

您现在可能担心直接与NT内核交流的麻烦。如果是这样，你可能会发现建议使用Boost.AFIO（ https://boostgsoc13.github.io/boost.afio/doc/html/afio.html ）。免责声明：我是它的作者。