子文件夹的最大允许深度是多少? [英] What is the maximum allowed depth of sub-folders?

问题描述

首先，我想问"Windows操作系统允许的最大子文件夹是什么"

但是后来我发现我的网络托管服务提供商可能不在Windows上，而是在Linux或其他操作系统上.所以我问一个虚拟主机提供商通常会使用的所有主要操作系统的最大允许子文件夹是多少. (可以肯定地说Linux，Mac或Windows吗?)

然后再次根据您的经验，虚拟主机网站是否限制了我们可以创建的子文件夹的数量?

(为什么?因为我希望每个用户都有自己的文件夹以方便访问其图像.可以吗?还是不好的做法?还是编程新手.)

解决方案

限制不是在嵌套子目录的深度上(您可以有几十个甚至更多)，而在文件系统及其配额上.

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

大多数文件系统(在Linux上)对其 inodes 的数量有固定的限制. /p>

某些文件系统在包含一万个条目的目录中表现不佳(例如，因为搜索是线性的而不是二分法的).而且您很难处理它们(例如，即使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 .

At first I wanted to ask "What is the maximum allowed sub-folder for a windows OS"

But then I figured maybe my web hosting provider isn't on windows but on linux or something else. So I'm asking what are the possible maximum allowed sub-folder for all major OS that a Web Hosting Provider would usually use. (Would it be safe to say Linux, Mac, or Windows?)

Then again, based on your experiences, do web hosting sites create a limit to the number of subfolders we can make?

(Why this? Because I want each user to have their very own folder for easy access to their images. Would that be ok? Or is it bad practice? Still new to programming.)

解决方案

The limit is not on the depth of the nested subdirectories (you could have dozens of them, even more), but on the file systems and its quotas.

Also having very long file paths is inconvenient (and could be slightly inefficient). Programmatically, a file path of several hundreds or even thousands of characters is possible; but the human brain is not able to remember such long file paths.

Most file systems (on Linux) have a fixed limit to their number of inodes.

Some file systems behave poorly with directories containing ten thousand entries (e.g. because the search is linear not dichotomic). And you have hard time to deal with them (e.g. even ls * gives too long output). Hence, it could be wise to have /somepath/a/0001 ... /somepath/z/9999 instead of /somepath/a0001 ... /somepath/z9999

If you have many thousands of users each with his directory, you might want to e.g. group the users by their initials, e.g. have /some/path/A/userAaron/images/foobar and /some/path/B/userBasile/images/barfoo etc. So /some/path/A/ would have only hundreds of subdirectories, etc...

A convenient rule of thumb might be: avoid having more than a few hundreds entries -either subdirectories or files- in each directory.

Some web applications store small data chunk in individual rows of a SQL databases and use files (whose name might be generated) for larger data chunks, storing the filepath in the database. Having millions of files with only a few dozen bytes in most is probably not efficient.

Some sysadmins are also using quotas on filesystems.

这篇关于子文件夹的最大允许深度是多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！