最初に、「Windows OS で許可される最大のサブフォルダーは何ですか」と尋ねたかったのです。
しかし、私の Web ホスティング プロバイダーは Windows ではなく、Linux などにあるのではないかと考えました。そこで、Web ホスティング プロバイダーが通常使用するすべての主要な OS で許可されるサブフォルダーの最大数を尋ねています。(Linux、Mac、または Windows と言うのは安全でしょうか?)
繰り返しになりますが、あなたの経験に基づいて、Web ホスティング サイトは、作成できるサブフォルダーの数に制限を設けていますか?
（これはなぜですか？各ユーザーに自分の画像に簡単にアクセスできるように独自のフォルダーを用意してもらいたいからです。それでいいでしょうか？それとも悪い習慣ですか？プログラミングはまだ初めてです。）
制限は、ネストされたサブディレクトリの深さ (数十、またはそれ以上) ではなく、ファイル システムとそのクォータです。
また、非常に長いファイル パスを持つことは不便です (そして、少し非効率になる可能性があります)。プログラムでは、数百または数千文字のファイル パスが可能です。しかし、人間の脳は、そのような長いファイル パスを覚えることができません。
ほとんどのファイル システム (Linux 上) には、inodeの数に固定の制限があります。
一部のファイル システムは、1 万のエントリを含むディレクトリで適切に動作しません (たとえば、検索が二分法ではなく線形であるため)。そして、それらに対処するのに苦労します (たとえば、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 データベースの個々の行に保存し、大きなデータ チャンクにはファイル (名前が生成される場合があります) を使用して、ファイルパスをデータベースに保存します。ほとんどが数十バイトしかない何百万ものファイルを持つことは、おそらく効率的ではありません。
一部のシステム管理者は、ファイルシステムでクォータも使用しています。
Windows では、任意のパスに 260 文字の制限があります。これにはファイル名が含まれるため、ファイルに260-directory path length.
これは、非常に多くのサブディレクトリを持つことができることを意味しますが、深くなるほど、最大ファイル名は短くなります。