ファイルサイズをゼロにするにはどうすればよいですか？

何かにぶつかって、適切な説明が思いつかなかった。PCで空の* .txtファイルを作成し、そのサイズを確認すると、0が表示されます。しかし、それはどのように可能ですか？つまり、ファイル自体が空であっても、ファイル自体の名前を保存するために、ある程度のサイズが必要です。これはどのように説明できますか？（非OS固有）

本当にファイルがないので可能です。名前と所有者を含むディレクトリエントリがあります。ディレクトリエントリは、ファイルとは論理的に区別されます。たとえば、複数のディレクトリで同じファイルに複数の名前を付けることができます。

残念ながら、「ファイル」という用語は、常に同じことを意味するために使用されるとは限りません。しかし、ファイルサイズロジックは、ディレクトリエントリがファイルをディレクトリに「アタッチ」し、ファイル名と関連するメタデータがディレクトリに保存されるモデルから派生しています。

「ファイルサイズ」の意味は、使用しているものとは異なります。

意味のある多くのファイルサイズがあります。最も一般的なものと、ここで見ているものは、「ファイル内のバイト数」です。ファイルが空のテキストファイルの場合、実際には0バイトが含まれている可能性があります。多くの場合、ファイルを開いて「すべてのデータを読み取って」閉じなければならないため、この数字はプログラマにとって重要です。事前に計画できるように、ファイルに含まれるデータのバイト数を知る必要があります。

別の意味は、ほとんどのファイルシステムがデータを保存する方法から生じます。ほとんどのファイルシステムは、ブロックにデータを保存します。たとえば、ファイルシステムは64kBブロックにデータを保存する場合があります。つまり、64kBの偶数倍でないものは割り当てられません。これは非効率に思えますが、簿記を非常に簡単にすることができます。

3番目の意味は、ファイルの存在を記述するためにハードドライブに必要な実際のビット数です。これには、通常、ファイルとは別に保存される情報が含まれます。たとえば、Linuxでは、「ファイル名」の概念はファイルを含むディレクトリのinodeに保存されます（編集：コメントから、技術的にはこれはディレクトリのデータに保存されます。これを書いたとき、私は小さな-ディレクトリの場合。156バイトより小さいデータは、iノードに直接保存できます。これは一般的に使用される意味ではありません。ファイルシステムの非常に深い内部動作を知らずに判断するのは非常に難しいからです（ファイルのすべてのアクセス許可を格納するために必要なスペースを考慮しましたか？）。ただし、1,000,000バイトのハードドライブがある場合は、

ファイル名は別の場所に保存されます。

ディスクには「ファイルシステム」があり、物理ディスク上でファイル名とファイルをどのように表現し解釈するかを選択する方法を単純に指定します。

「NTFS」（New Technology File System）というファイルシステムを使用するほとんどのWindowsディスクでは、ファイルの内容とは別に、マスターファイルテーブル（MFT）にファイル名情報を保存します。マスターファイルテーブルに関するウィキペディアの記事を参照してください。

したがって、ファイル自体の長さは0バイトになりますが、MFT内のエントリはまだスペースを占有します。

これは非常に興味深い存在論的質問です...

ファイル自体はファイルのコンテンツです。ファイルにコンテンツがない場合、サイズはゼロになります。ファイル名は、自分の名前が物理的にあなたの一部であるのと同じくらいファイルの一部です（つまり、そうではありません）。

あなたの名前が人々の頭（そしてあなた自身）に物理的なあなたを参照/ポイントするアイデアとして存在するように、ファイル名はファイルシステムのディレクトリツリーに存在し、ファイルを参照/ポイントします。

（答えに少し遅れて...）

ファイルのサイズをゼロにする方法は、上記の回答よりも少し複雑です。質問にはWin7というタグが付けられていますが、FATやNTFSなどの他の「よりシンプルな」ファイルシステムを見ると、概念が似ているので便利です。

ディスクは、ファイルとディレクトリを「認識」しません。それは小さなブロックのすべてのデータです。OSは、データブロックの意味を区別します。最初のいくつかは特別ですが、残りのブロックはデータに関する情報（例：ファイル名、ファイル長、データを保持する最初のデータブロック）、またはデータ自体を保持します。

ディレクトリは特別な「ファイル」であり、その「データ」がOSが理解するのは、ファイルの内容ではなく、ファイルに関する情報を含む情報ブロックです。良い例えは、物理ライブラリとカードカタログです。情報ブロックをカードカタログと考え、棚をデータブロックと考えてください（カードカタログも棚のような構造になっています）。

（たとえばUNIX touchコマンドを使用して）ファイルを「作成」すると、OSは最初に情報ブロック（ディレクトリ）に次のエントリを作成します。

• 名前= My_File.txt
• 長さ= 0
• 開始データブロック= N / A
• 追加情報（所有者、権限、作成/更新/変更日）など

「書き込む」データがある場合のみ、空のデータブロックを見つけてデータを保存しようとします。ただし、データブロックは固定サイズ（たとえば32K）で提供され、ディスクにアクセスしたりOSが読み取ったりするのに便利です。「Hello」のみを記述した場合、ブロックの大部分は「空」になります（実際はゼロではないかもしれませんが、以前に存在していたものからのゴミです）。ファイル）ので、悪いものを取得しないでください。

「ファイル」を長さ>ブロックサイズに更新すると、OSはデータを新しいブロックに書き込み、データブロックを更新して、ファイルが最初の（その後など）後に次のブロックに続き、長さが更新されると言います新しい長さ（詳細は異なります）。

最終的には、データブロックのチェーン（ファイルの内容）に関する情報を含む情報データブロック（ディレクトリまたはリスト）のコレクションになります。

論理的には、同じファイルシステムでのファイルの移動が高速で点滅しているのにコピーに時間がかかる理由も説明しています。OSは、2つのディレクトリブロックを編集して、1つのディレクトリ（情報データブロック）からエントリを削除し、別のディレクトリに追加するだけです。ファイルの削除：ディレクトリブロックのエントリを削除するだけで、ファイルデータブロックを解放して再割り当てできます。

ps：カードカタログに本のエントリがあるからといって、それが棚にあることを意味するわけではありません（おそらくチェックアウトまたは紛失）。ファイルサイズ0。

pps：ライブラリ内の場所を間違えた本は、検索ライブラリを意味します。コンピューター用語では、chkdskまたはリペアディスクです。

UNIX iノードについて読んだり、バージョン管理システム（ClearCase、TFS、Gitなど）がファイルやディレクトリだけでなく、ファイルのバージョンやディレクトリのバージョンを管理する方法を理解することで、より深い理解を得ることができます。ほとんどの場合、すべてがデータベースに保存され、ユーザーに表示されて、古典的なディレクトリ構造とファイルとして表示されます！

ここにいくつかの優れた答えがあります-私は絵のバージョンを追加したいと思います（千の言葉など）

これは、ディスクデフラグツールで視覚化した場合、NTFSフォーマットのハードドライブの1つです。MFT（マスターファイルテーブル）は紫で示されています：

その小さなすみれ色の正方形は、HDにあるファイルのリストを示しています。大まかに言うと、NTFSディスクの場合、目次は本のことです。ページの代わりに、ディスク^1の残りの物理的な場所を指します。

サイズが0バイトのファイルは、ページがまったくないことを指す目次エントリとして視覚化できます。

エントリはリストされていますが、ページが示されていないため、コンテンツが存在しないと想定できます。

^{1-確かに、それよりも少し複雑です。ただし、セクターマップ、ミラーMFTなどの点はこの質問の範囲外です。}

ファイルシステムは、ファイル名、ファイルサイズ、作成時間、アクセス時間、変更時間、作成されたユーザー、ユーザーとグループのパーミッション、フラグメント、ファイルを保存するクラスターへのポインター、ハード/ソフトリンク、属性などのファイルに関する多くの情報を保存します...これらはファイルメタデータと呼ばれます。ユーザーがそれらを気にせず（必要とせず）、それらについて知らないのに、なぜそれらのメタデータをファイルサイズに数えるのですか？彼らは本当にファイルの内容だけを気にします

さらに、各ファイルシステムには、ディスク上の異なる量のスペースを取る異なるタイプのメタデータが格納されます。たとえば、POSIXアクセス許可はNTFSアクセス許可とは大きく異なりinode、POSIXにはWindowsには存在しない数字もあります。POSIXファイルシステムでさえ、32ビットブロックアドレスを持つext3、48ビットを持つext4、64ビットを持つBtrfs、128ビットアドレスを持つZFSなど、さまざまです。では、これらのメタデータをファイルサイズにどのようにカウントしますか？

現在のファイルシステムでメタデータが56バイトを消費する100バイトのファイルを使用した別の例を見てみましょう。ファイルを別のファイルシステムにコピーすると、128バイトのメタデータが必要になります。ただし、ファイルの内容はまったく同じであり、ファイルのバイト数も同じです。そのため、システム上でファイルサイズを156バイト、別のシステムでは228バイトと表示すると、非常にわかりにくく直感に反します。

のファイルサイズは0、「5言葉が書かれた紙を持っている」という言い方に似ています。そして別の論文では、0言葉が書かれています。だから0完全に可能です。

ファイルのメタデータ（作成日時、最終更新日時、ファイル所有者、アクセス許可）は、ファイルサイズの一部として含まれる場所以外にすべて保存されます。

簡単な方法でそれを理解してください...ファイルを作成すると、提供されたファイル名で識別されるファイルのメモリ位置へのポインタとして機能するディレクトリエントリが生成されます。ポインタの作成やファイルの作成が増えると、ディレクトリのサイズが大きくなります。一方、ファイルサイズは、指定した場所、つまりファイル自体の中にいくつかのデータを配置した場合にのみ増加します。それまでは、サイズはゼロになります。:)

そのため、次のように機能します。

ボリューム上にファイルを作成するとすぐに、NTFS mataファイルにファイルレコード、つまり$ MFT（マスターファイルテーブル）が作成されます。MFTにFRS（ファイルレコードセグメント）が存在するため、レコードが表示されます。NTFS FileSystemの場合、各ファイルレコードのサイズはデフォルトで1 KBです。しかし、そのスペースは、ファイル内に何らかの情報を保存する場合にのみ要求されます。テキストファイルであることを考慮して1文字の "a"を記述しただけでも、それがFRSのデフォルトサイズであるため、1 KBのスペースを要求します。文字「a」は、そのFRSのデフォルトの名前のないデータストリーム、ADS（Alternate Data Stream）がない場合にすべてのデータが移動する属性である$ Dataに移動します。

何か質問があれば教えてください。

• NTFS ファイルの成長の詳細については。
• 詳細についてはNTFSメタファイル。