Windows で空のファイルやフォルダーが 0 バイトになるのはなぜですか?

Question

Linux に関する兄弟の質問もしました。

違いがあるとすれば、それはWindowsとLinuxの間ではなく（そして、あなたは本当にmacOSやSolarisなどに同じ質問をするつもりですか？）、実際のファイルシステムディスク上にファイルを保存するために使用されます。

ただし、各OSにはそれぞれ推奨されるファイルシステムがあり、WindowsのFAT32はLinuxのFAT32と同じように動作し、LinuxのNTFSはWindowsのNTFSと同じように動作します。同時に、同じOS上のさまざまなファイルシステムは、互いに非常に異なる動作をする可能性があります。Ext4とBtrfs（またはFAT32とNTFS）は、マイル同じ OS であっても、区別がつきます。

空のファイルのサイズは0バイトとして示されます

いずれの場合も、報告されるファイルサイズはいつも実際のコンテンツのみであり、メタデータではありません。現在使用されているほぼすべてのファイルシステムでは、これらを 2 つの別個のものとして扱います。ファイルが名前とデータが結合されて構成されていると想像しているのであれば、いいえ、通常はそうではありません。

ファイル名は多くの場合親ディレクトリ内(これにより、ハードリンク、つまり 1 つのファイルに複数の名前を持たせることも可能になります)。そのため、ファイル名が長いと、親ディレクトリが大きく見える場合があります。

ファイル関連のメタデータの残りは、名前の近くにある場合もあれば、より一般的には別の領域 (例: inode テーブル) にある場合もあります。

これらのデータを保存するために使用できる最大メモリは、事前に定義された数値ですか、それともディスク内の使用可能なスペースに依存しますか?

さまざまです。ファイルシステムの種類ごとに独自の制限があります。最大値が固定されているものもあれば、ディスクの特定の割合に制限されているものもあります。

たとえば、FAT では、各ディレクトリには「ディレクトリエントリ」の最大数が制限されています (MS-DOS スタイルの 8.3 ファイル名はそれぞれ 1 つのエントリを占めますが、長いファイル名は複数のエントリを占めます)。これは、どちらも Windows 上にあるにもかかわらず、NTFS には適用されません。

Ext2/Ext4 では、ファイルシステム全体は、固定サイズのレコードのリストとして保存される一定量の「inode」（ファイルまたはディレクトリごとに 1 つ）に制限され、領域は常にディスク領域の固定パーセンテージに設定されます。Ext4 ディスクで inode が不足することは珍しくありません。これは、動的なデータ構造（通常は B ツリー）を使用し、要求に応じて単純に拡張する XFS または Btrfs には当てはまりません。

短い名前の空のフォルダーは、長い名前の空のフォルダーよりもスペースをあまり取りませんでしょうか? (または、これらの名前が格納されるデータ構造では、ファイルごとに固定のバイト数があり、残りのバイトが \0 で埋められる可能性がありますか?)

さまざまです。一部の (ほとんどの?) ファイルシステムでは、名前は可変長です。

他のファイルシステムでは、特定のしきい値でのみ発生します。ここでも、固定サイズのディレクトリスロットを持つ FAT/exFAT および UFS が例になります。スロットが占有されている場合は、ヌルバイトで埋め込まれた 1 バイトのファイル名が格納されているか、16 バイトのファイル名が格納されているかに関係なく、占有されたままになります。

foobar という空のフォルダーは、foobar という空のファイルよりも少ないスペース、同じスペース、それともより多くのスペースを占めますか?

繰り返しますが、これはファイルシステムに依存します。

FAT では、私の理解が正しければ、それらは同じです。NTFS では、フォルダーが大きくなるのではないかと思いますが、現時点では推測しているだけです。

C:\empty.txt にある空のファイルは、C:\long\nested\path\until\the\empty\file\is\reached\empty.txt にある空のファイルよりも少ないスペース、同じスペース、またはより多くのスペースを占めますか?

ファイル自体ファイルはパス全体を知らないため、常に同じです。OS は親ディレクトリを下ってファイルを見つけます。これはおそらくすべてのファイルシステムで共通です。

ただし、これらのフォルダーはゼロ以外のスペースを占有します。

Answer 1