子文件夹的最大允许深度是多少？答案

【问题标题】：What is the maximum allowed depth of sub-folders?子文件夹的最大允许深度是多少？
【发布时间】：2013-03-09 03:36:09
【问题描述】：

起初我想问“Windows 操作系统允许的最大子文件夹是多少”

但后来我想也许我的网络托管服务提供商不在 Windows 上，而是在 linux 或其他东西上。所以我问的是，Web 托管服务提供商通常会使用的所有主要操作系统允许的最大子文件夹是多少。（说 Linux、Mac 或 Windows 是否安全？）

再一次，根据您的经验，网络托管网站是否会限制我们可以创建的子文件夹数量？

（为什么？因为我希望每个用户都有自己的文件夹，以便轻松访问他们的图像。这样可以吗？或者这是不好的做法？还是编程新手。）

【问题讨论】：

我相信没有 sane 硬上限。期望值大约为 2^32。即使是 2^16 也很正常。你很快就会遇到其他问题。
@JanDvorak 你能请。解释一下？
我的意思是，早在您遇到“达到每个文件夹的最大子文件夹数”之前，列出目录将花费非常长的时间（相信我，列出包含数百个子文件夹的文件夹需要非常长时间SSH），否则您将耗尽磁盘空间。
这更清楚。谢谢！
顺便说一句，folder 术语在 Unix 上并不常见。请谈谈目录

标签： linux windows macos directory subdirectory

【解决方案1】：

限制不是嵌套子目录的深度（你可以有几十个，甚至更多），而是文件系统及其配额。

还有很长的文件路径很不方便（并且可能效率稍低）。以编程方式，数百甚至数千个字符的文件路径是可能的；但是人脑无法记住这么长的文件路径。

大多数文件系统（在 Linux 上）对其inodes 的数量都有固定限制。

某些文件系统在处理包含一万个条目的目录时表现不佳（例如，因为搜索是线性的而不是二分法的）。而且您很难处理它们（例如，即使ls * 给出的输出太长）。因此，使用 /somepath/a/0001 ... /somepath/z/9999 而不是 /somepath/a0001 ... /somepath/z9999 可能是明智之举

如果您有成千上万的用户，每个用户都有自己的目录，您可能希望例如按用户姓名首字母对用户进行分组，例如有/some/path/A/userAaron/images/foobar 和/some/path/B/userBasile/images/barfoo 等。所以/some/path/A/ 将只有数百个子目录等......

一个方便的经验法则可能是：避免有超过几百个条目-子目录或文件-每个目录中。

一些 Web 应用程序将小数据块存储在 SQL 数据库的各个行中，并将文件（可能会生成其名称）用于较大的数据块，并将文件路径存储在数据库中。拥有数百万个只有几十个字节的文件可能效率不高。

一些系统管理员也在文件系统上使用quotas。

【讨论】：

谢谢@basilesarynkevitch！你的回答解释了很多！并感谢您的分组提示。我将尝试创建一个考虑到该过程的系统。
很好的答案，“二分法”这个词并不代表你的想法。
法语是这样。

【解决方案2】：

在 Windows 中，任何路径中的字符数限制为 260 个。这包括文件名，因此文件的字符数不能超过260-directory path length。

这意味着您可以拥有相当多的子目录，但随着您的深入，最大文件名会变短。

【讨论】：

大多数虚拟主机不是基于 Windows...在 Linux 上，限制要大得多（至少 1024，可能更多）。
@Basile：确实如此。然而，问题是“所有主要操作系统”。虽然 Linux 可能更为常见，但我知道有数十家提供 Windows 的托管公司
@BasileStarynkevitch：在 linux 上，可用的文件系统要多得多，而文件系统将决定这一点。例如，您可以在 linux 安装上使用 NTFS（可以，不应该）。在这种情况下，您将回到最多 260 个字符路径...对于更常见的文件系统，例如 ext2 或 ext3，限制实际上是 32k
很有趣，我记得在 Windows XP 时代（也许现在仍然如此？）您可以安装的字体数量仅限于字体文件的组合文件名长度。限制某些东西的非常荒谬的方式。

【解决方案3】：

其他非常重要的是性能。对于 Windows，如果您开始获取超过 5k 的文件，它开始变慢，10k 它正在爬行，而 50k 变得完全无法使用！

【讨论】：