Jo *_* E. 8 linux windows directory macos subdirectory
起初我想问"Windows操作系统允许的最大子文件夹是什么"
但后来我想也许我的网络托管服务提供商不是在Windows上,而是在Linux或其他东西上.所以我想问一下,网络托管服务提供商通常会使用的所有主要操作系统的最大允许子文件夹是什么.(说Linux,Mac或Windows会安全吗？)
然后,根据您的经验,网站托管网站是否限制了我们可以制作的子文件夹数量？
(为什么会这样？因为我希望每个用户都有自己的文件夹,以便轻松访问他们的图像.这样可以吗？或者这是不好的做法？编程还是新手.)
限制不在于嵌套子目录的深度（您可以有几十个子目录，甚至更多），而在于文件系统及其配额。
另外，文件路径过长也很不方便（可能效率不高）。以编程方式，可能有数百个甚至数千个字符的文件路径。但是人脑无法记住这么长的文件路径。
大多数文件系统（在Linux上）对inode的数量有固定的限制。
一些文件系统在包含一万个条目的目录中表现不佳（例如，因为搜索是线性的而不是二分法的）。而且您很难处理它们（例如，甚至ls *给出了太长的输出）。因此，用/somepath/a/0001... /somepath/z/9999代替/somepath/a0001... 可能是明智的。/somepath/z9999
如果您的目录中有成千上万的用户，则可能需要按用户的姓名首字母对它们进行分组，例如have /some/path/A/userAaron/images/foobar和/some/path/B/userBasile/images/barfooetc。因此/some/path/A/只有数百个子目录，等等。
一个方便的经验法则可能是：避免在每个目录中有数百个条目（子目录或文件）。
一些Web应用程序将较小的数据块存储在SQL数据库的各个行中，并使用文件（可能会生成其名称）来存储较大的数据块，并将文件路径存储在数据库中。拥有数百万个最多只有几十个字节的文件可能效率不高。
一些系统管理员也在文件系统上使用配额。
在 Windows 中，任何路径中的字符数限制为 260 个。这包括文件名，因此文件的字符数不能多于260-directory path length.
这意味着您可以拥有相当多的子目录，但随着深入，最大文件名会变得更短。