偶然遭遇したのですが、適切な説明が思いつきませんでした。PC に空の *.txt ファイルを作成し、そのサイズを確認すると 0 と表示されます。しかし、どうしてそうなるのでしょうか? つまり、ファイル自体は空であっても、ファイルの名前を保存するために、ある程度のサイズが必要です。これはどのように説明できますか? (OS に依存しません)
答え1
実際にはファイルが存在しないので、これが可能です。名前と所有者を持つディレクトリ エントリがあるだけです。ディレクトリ エントリは、ファイルとは論理的に区別されます。たとえば、同じファイルが複数のディレクトリで複数の名前を持つことができます。
残念ながら、「ファイル」という用語は、必ずしも正確に同じ意味で使用されるわけではありません。しかし、ファイル サイズのロジックは、ディレクトリ エントリがファイルをディレクトリに「添付」し、ファイル名と関連するメタデータがディレクトリに保存されるモデルから来ています。
答え2
「ファイル サイズ」の意味は、使用しているものとは異なります。
意味のあるファイル サイズは多数あります。最も一般的なサイズ、そしてここで表示されているサイズは、「ファイル内のバイト数」です。ファイルが空のテキスト ファイルである場合、実際には 0 バイトが含まれている可能性があります。この数値は、ファイルを開いて「すべてのデータを読み取り」、ファイルを閉じる必要があることが多いため、プログラマーにとって重要です。事前に計画を立てるために、ファイル内のデータのバイト数を知る必要があります。
もう 1 つの意味は、ほとんどのファイル システムがデータを保存する方法から生じます。ほとんどのファイル システムは、データをブロック単位で保存します。たとえば、ファイル システムは 64kB のブロック単位でデータを保存する場合、64kB の偶数倍でないものは割り当てられません。これは非効率的に思えますが、記録をかなり簡単にすることができ、多くの場合、簡単であるということは高速であることを意味します。
あなたが探している 3 つ目の意味は、ファイルの存在を記述するためにハードドライブ上で必要な実際のビット数です。これには、通常ファイルとは別に保存される情報が含まれます。たとえば、Linux では、「ファイル名」の概念は、ファイルを含むディレクトリの inode に保存されます (編集: コメントによると、技術的にはこれはディレクトリのデータに保存されます。これを書いたとき、私は小さなディレクトリの場合を考えていました。156 バイト未満のデータは inode に直接保存できます)。これは、ファイル システムの非常に深い内部動作を知らないと判断するのが非常に難しいため、一般的に使用される意味ではありません (ファイルのすべての権限を保存するために必要なスペースを考慮しましたか?)。ただし、1,000,000 バイトのハード ドライブがあり、そのハード ドライブに収まるファイル サイズを知りたい場合は、これが非常に重要な意味になります。
答え3
ファイル名は別の場所に保存されます。
ディスクには「ファイル システム」があり、簡単に言えば、物理ディスク上でファイル名とファイルがどのように表現され、解釈されるかを選択する方法です。
ほとんどのWindowsディスクでは、「NTFS」（New Technology File System）と呼ばれるファイルシステムが使用されています。これは、ファイル名情報をファイルの内容とは別にマスターファイルテーブル（MFT）に保存します。マスターファイルテーブルに関するWikipediaの記事。
したがって、ファイル自体の長さは 0 バイトになりますが、MFT 内のエントリは依然としていくらかのスペースを占有します。
答え4
（回答が少し遅くなりましたが…）
ファイルサイズをゼロにする方法は、上記の回答で説明されているよりも少し複雑です。質問はWin7でタグ付けされていますが、他の「より単純な」ファイルシステムを見てみましょう。脂肪またはNTFSは概念が似ているため役に立つかもしれません。
ディスクは、ファイルとディレクトリが何かを「認識」しません。すべては小さなブロック内のデータです。OS はデータ ブロックの意味を区別します。最初の数ブロックは特別ですが、残りのブロックには、データに関する情報 (例: ファイル名、ファイルの長さ、データを保持する最初のデータ ブロック) またはデータ自体が保持されます。
ディレクトリは特別な「ファイル」であり、OS はディレクトリの「データ」をファイルの内容ではなく、ファイルに関する情報を含む情報ブロックとして理解します。物理的な図書館とカード カタログを例に挙げるとわかりやすいでしょう。情報ブロックをカード カタログ、棚をデータ ブロックと考えてください (カード カタログも棚のような構造になっています)。
ファイルを「作成」すると (UNIXtouchコマンドなどを使用して)、OS はまず情報ブロック (ディレクトリ) に次のエントリを作成します。
- 名前 = My_File.txt
- 長さ = 0
- 開始データブロック = N/A
- 追加情報（所有者、権限、作成日/更新日/変更日）など
「書き込む」データがある場合のみ、データを格納するための空のデータ ブロックを探します。ただし、データ ブロックは、ディスクがアクセスしやすく、OS が読みやすいように固定サイズ (たとえば 32K) になっています。「Hello」のみを書き込む場合、ブロックの大部分は「空」です (実際にはゼロではなく、以前あったデータからのゴミである可能性があります)。そのため、テーブルはサイズを長さ (たとえば 5 文字 + ファイルの終わり) に更新し、問題のあるデータを取得しないようにします。
「ファイル」を長さ > ブロック サイズに更新すると、OS はデータを新しいブロックに書き込み、データ ブロックを更新して、ファイルが最初のブロックの後に次のブロックに続くことを示します (以下同様)。また、長さが新しい長さに更新されます (詳細は異なります)。
最終的に得られるのは、データ ブロック (ディレクトリまたはリスト) のチェーンに関する情報を含む情報データ ブロックのコレクションです。
論理的に、これは、同じファイルシステム上のファイルの移動が高速であるのに対し、コピーには長い時間がかかる理由も説明しています。OS は、1 つのディレクトリ (情報データ ブロック) からエントリを削除し、別のディレクトリに追加するために、2 つのディレクトリ ブロックを編集するだけで済みます。ファイルを削除するには、ディレクトリ ブロック内のエントリを削除するだけで、ファイル データ ブロックが解放され、再割り当てされます。
追伸: カード カタログに書籍のエントリがあるからといって、その書籍が棚にある (貸し出し中か紛失している) ことを意味するわけではありません。ファイル サイズは 0 です。
pps: ライブラリ内の置き忘れた本は、ライブラリの検索、またはコンピューター用語で言うと chkdsk またはディスクの修復を意味します。
UNIX inode について読んだり、バージョン管理システム (ClearCase、TFS、Git など) がファイルやディレクトリだけでなく、ファイルのバージョンやディレクトリのバージョンも管理する方法を理解したりすると、より深く理解することができます。ほとんどの場合、すべてがデータベースに保存され、ユーザーには従来のディレクトリ構造とファイルとして表示されます。