我可以在一个 Windows 文件夹中放入多少个文件夹？

Question

我可以在一个 Windows 文件夹中放入多少个文件夹？

Abd*_*rif 24 windows windows-explorer filesystems windows-server file-organization

我有一个 10M 的文件夹。每个文件夹包含 13 个文件。

我想将所有这些文件夹放在一个主文件夹（根）中。

Windows Server 对此有任何限制吗？

Answer 1

这可能是X/Y 问题。也许您正在做的事情更适合数据库而不是文件系统。使用数据库，您可以轻松快速高效地存储和访问数百万条记录。接受的答案是正确的，说 NTFS 理论上能够存储这么多记录，但速度不会很快。这基本上适用于所有文件系统（例如 NTFS、exFAT、ext4、HFS...）。它们根本就没有被设计为对您正在尝试做的事情具有足够的可扩展性。

造成这种情况的主要原因之一是大多数操作系统的文件系统 API 只能一次返回整个目录条目列表。例如，无法仅检索与典型文件系统中的特定模式匹配的目录。它必须全部检索它们，然后为您想要的名称解析（大量）输出。除了大小、创建和修改时间等名称之外，其他文件/目录属性也是如此。数据库不是这种情况。

甚至 NTFS 比 DOS FAT 更接近于 OS/2 的 HPFS（尽管它在任何情况下都是从头开始设计的，如果您可以在任何地方找到它，请参阅 Helen Custer 的 *Inside the Windows NT File System*。我认为 exFAT 可能是唯一的系统在那个实际上起源于 DOS 的列表中。 (6认同)
“文件系统 API 只能一次返回整个目录条目列表”。真的是这样吗？Win32 API 允许您只返回特定模式的文件，还允许您一个接一个地查询文件（FindFirstFile/FindNextFile 等）。这似乎可以很好地支持预期的场景。如果 *Nix 没有类似的 API，我会感到惊讶。许多应用程序可能会处理这种情况很糟糕，但 API 本身似乎支持这种情况。 (5认同)
小记 - ext4 是从 ext3 演变而来的，ext3 是从 ext2 演变而来的，而 ext2 是从早于 DOS 的 BFS/UFS 演变而来的。HFS 同样具有与 DOS FAT 无关的演变。 (3认同)

Answer 2

har*_*ymc 43

就NTFS的理论容量而言，没有问题。

Microsoft 关于NTFS 卷上最大大小的文章指定每个卷的最大文件数为 4,294,967,295，这也应该是文件夹的最大值。但是，您需要一台速度非常快且具有大量 RAM 的计算机才能在资源管理器中查看该文件夹。

根据我自己的经验，在几年前的一台好电脑上，查看一个包含数千个子文件夹的文件夹需要几十秒钟才能显示该文件夹。我不知道 1000 万个子文件夹会发生什么，但是即使计算机可以处理它，您肯定也需要很大的耐心。最终。

我真的建议重新考虑您的文件夹架构。

OP 从未提到他想在资源管理器上查看文件。 (10认同)
如果有人好奇 4,294,967,295 是从哪里来的，那就是 2^32-1。 (7认同)
在实践中，大量文件夹通常位于临时、缓存、上传和其他以编程方式管理的文件夹中，这些文件夹不打算使用资源管理器查看。通常文件夹内容从不列出，文件是使用存储在数据库中的哈希或路径访问的。 (4认同)
特别是，即使 NTFS 将数据存储在 B+ 树（或 B* 树？）中，Windows 也仅提供顺序机制来列出目录。所以你可能想假设会发生线性搜索...... (3认同)
附上关于可用性问题的观点。在这种情况下，OP 可能想要一个数据库，但如果不是，他们几乎肯定_需要_进行某种目录散列以生成更深嵌套的树结构，每个级别的扇出都低得多，以使其甚至可以远程使用. (2认同)

Answer 3

phu*_*clv 27

文件夹内的文件数与操作系统无关。这是文件系统的一个特性，尽管您使用的系统可能具有较低的限制。一些文件系统限制文件夹中的文件数，而另一些文件系统仅限制卷中的文件总数，而有些则根本没有任何限制。请参阅文件系统的限制。请注意，基本上目录只是一个文件，其内容是其他文件的列表

如果您使用exFAT，则每个文件夹的最大数量为2 796 202 个文件。在NTFS 中，每个卷的限制是 2 ³² -1 个文件。如果您使用FAT，则限制取决于 FAT 版本

FAT12：4 068 用于 8 KiB 集群
FAT16：32 KiB 集群为 65 460
FAT32：268 173 300 用于 32 KiB 集群

Windows 还原生支持一些其他文件系统，如 ReFS，或者您可以为其他非原生文件系统安装驱动程序。他们又可能有不同的限制

但无论如何，在一个文件夹中存放大量文件都是一个非常糟糕的主意。列表和运行速度取决于文件系统如何存储其元数据，例如在 FAT 中它是一个线性列表，所以它非常慢。但是即使使用一种有效的方法来列出 NTFS 中的 B+树等文件，它仍然很慢。一般来说，我避免在一个文件夹中有超过 2000 个文件

在您的情况下更好的解决方案应该是某种数据库。但是，如果您真的必须将文件直接存储在驱动器中，那么您需要将文件均匀分布到多个较小的文件夹中。常见的方法是对文件名或内容进行散列，然后拆分为具有该名称一部分的文件夹。例如，如果散列是0xabcdef12（32 位），则将文件存储在ab/cd/ef/12,ab/cde/f12或2af/0de/f12（每个路径组件分别代表原始值的 8/8/8/8、8/12/12 和 10/10/12 位）。这样，任何文件夹都不应该有太多或太少的文件。看

这种方法在git或者docker中常用

也可以看看

“文件夹内的文件数量与操作系统无关。这是文件系统的一个特性。” – 如果文件系统支持 100000 个文件，但操作系统要求每个文件都有一个唯一的编号，并且要求该编号的类型为 16 位整数，那么就会存在操作系统强加的限制。正确的说法是限制是文件系统限制、操作系统限制和用于访问文件的工具限制中的最小值。*特别是*在 Windows 上，有大量奇怪的限制在 NTFS 中不存在，但存在于不同的 API 和资源管理器中。 (12认同)
@downvoter：这有什么问题吗？ (3认同)
特别是，Windows 支持多种不同的 API 以实现向后兼容性，它们可能有不同的限制，OP 使用的工具可能会使用这些 API 中的一种。 (2认同)
@NotThatGuy 没有人手动遍历数百万个文件和文件夹。即使您将文件分发到其他一些规则，那么某些文件夹可能有数百万个文件，而其他文件夹只有几个文件，这根本没有改进。正如我所说，强烈建议使用适当的数据库 (2认同)
@NotThatGuy 在评论中“遍历”意味着手动进入子文件夹。只有在这种情况下，您才关心文件夹名称的含义。自动化代码从不关心这个，所以散列就足够了，而且更好。除了文件夹太大之外，自动化代码查找特定文件的速度也较慢 (2认同)

归档时间：	4 年，10 月前
查看次数：	9363 次
最近记录：	4 年，10 月前