ファイルサイズをゼロにするにはどうすればよいですか。
ただ私が遭遇した、そして正しい説明を考えることができなかった何か。 PC上で空の* .txtファイルを作成し、そのサイズを確認すると、0と表示されます。しかし、それはどうすれば可能ですか？ファイル自体が空であっても、それ自身の名前を格納するために、まだある程度のサイズが必要です。これはどのように説明できますか？ （OS非対応）
本当にファイルがないのでそれは可能です。名前と所有者を持つディレクトリエントリだけがあります。ディレクトリエントリはファイルとは論理的に異なります。たとえば、同じファイルが複数のディレクトリに複数の名前を持つことができます。
残念ながら、「ファイル」という用語は必ずしも正確に同じものを意味するために使用されているわけではありません。しかし、ファイルサイズロジックは、ディレクトリエントリがファイルをディレクトリに「アタッチ」し、ファイル名と関連メタデータがディレクトリに格納されるというモデルに由来します。
「ファイルサイズ」の意味は、使用しているものとは異なります。
意味のあるファイルサイズはたくさんあります。最も一般的なもの、そしてここで見ているものは、「ファイルのバイト数」です。ファイルが空のテキストファイルであるなら、それは確かに0バイトを含むかもしれません。この数はプログラマにとって重要です。なぜなら私たちはしばしばファイルを開いて「すべてのデータを読んで」それを閉じる必要があるからです。計画を立てるために、ファイルに何バイトのデータが入るかを知る必要があります。
別の意味は、ほとんどのファイルシステムがデータを保存する方法から生じます。ほとんどのファイルシステムはデータをブロックに格納します。たとえば、ファイルシステムは64kBブロックにデータを格納できます。つまり、64kBの偶数倍ではないものは割り当てられません。これは非効率的に聞こえますが、簿記を非常に簡単にすることができ、そしてより簡単なことはしばしばより速いことを意味します。
あなたが引っ張っている3番目の意味は、ファイルの存在を記述するためにハードドライブ上で必要とされる実際のビット数です。これには、通常ファイルとは別に格納されている情報が含まれます。たとえば、Linuxでは、 "filename"の概念はファイルを含むディレクトリのinodeに格納されています（編集：コメントから、厳密にはディレクトリのデータに格納されています）。 156バイト未満のデータは、iノードに直接格納できます。これは一般的に使用される意味ではありません。ファイルシステムの非常に深い内部動作を知らずに判断するのは非常に難しいからです（ファイルに対するすべての許可を格納するために必要なスペースを考慮しましたか？）。しかし、もしあなたが1,000,000バイトのハードドライブを持っていて、そのハードドライブにどれだけのファイルが収まるのか知りたいのなら、これはあなたにとって非常に重要な意味になるでしょう！
ファイル名は別の場所に保存されます。
ディスクには「ファイルシステム」があり、物理ディスク上でファイル名とファイルをどのように表現し解釈するかを選択する方法を単純に指定します。
「NTFS」（New Technology File System）と呼ばれるファイルシステムを使用するほとんどのWindowsディスクでは、ファイルの内容とは別にマスターファイルテーブル（MFT）にファイル名情報が保存されます。 Wikipediaの記事マスターファイルテーブル 。
したがって、ファイル自体の長さは0バイトになりますが、MFT内のエントリはまだスペースを占有します。
これは非常に興味深い存在論的質問です...
ファイル自体はファイルの内容です。ファイルにコンテンツが含まれていない場合、サイズは0です。ファイル名は、あなた自身の名前が物理的にあなたの一部であるのと同じくらいファイルの一部です（すなわち、そうではありません）。
あなたの名前が人々の頭の中に（そしてあなた自身の）アイデアとして存在し、物理的なあなたを参照/指しているように、ファイル名はファイルシステムのディレクトリツリーに存在し、ファイルを指しています。
（ちょっと答えに遅れます…）
ファイルのサイズをゼロにする方法は、上記の回答で提供されるものよりも少し複雑です。質問はWin7とタグ付けされていますが、 FAT や NTFSのような他の「より単純な」ファイルシステムを見ています。 は、概念が似ているため便利です。
ディスクは、ファイルとは何か、ディレクトリとは「認識」していません。それはすべて小さなデータです。 OSはデータブロックの意味を区別します。最初のいくつかは特別ですが、残りのブロックはデータに関する情報（例：ファイル名、ファイル長、データを保持している最初のデータブロック）、またはデータそのものを保持します。
ディレクトリとは、OSが認識する「データ」とは、ファイルの内容ではなく、ファイルに関する情報を含む情報ブロックのことです。良い例えは、物理的な図書館とカードカタログです。情報ブロックをカードカタログ、棚をデータブロックと見なします（カードカタログも棚のような構造になっています）。
ファイルを「作成」すると（UNIXのtouchコマンドを使用する場合）、OSは最初に情報ブロック（ディレクトリ）に次のエントリを作成します。
- 名前= My_File.txt
- 長さ= 0
- 開始データブロック= N/A
- 追加情報（所有者、許可、作成/更新/修正日）など
「書き込む」データがある場合にのみ、データを格納するために空のデータブロックを見つけようとします。しかし、データブロックは固定サイズ（例えば32K）になっており、ディスクがアクセスし、OSが読み取るのに便利です。 「Hello」とだけ書いた場合、ほとんどのブロックは「空」です（実際はゼロではないかもしれませんが、以前のものからのゴミです）ので、テーブルもサイズを長さに更新します（例えば5文字+ End of） File）だから、あなたは悪いものを手に入れないでください。
「ファイル」を長さ>ブロックサイズに更新すると、OSはデータを新しいブロックに書き込み、データブロックを更新してファイルが最初のブロックの次のブロックに続くようにします（以下同様）。新しい長さ（詳細は異なります）。
最終的に得られるのは、データブロックのチェーン（ファイルの内容）に関する情報を含む情報データブロック（ディレクトリまたはリスト）の集まりです。
論理的には、これはまた、同じファイルシステム上でのファイル移動が速く点滅しているのに、コピーに時間がかかる理由を説明しています。 １つのディレクトリ（情報データブロック）からエントリを削除して別のディレクトリに追加するには、ＯＳは２つのディレクトリブロックを編集するだけでよい。ファイルを削除する：ディレクトリブロック内のエントリを削除し、ファイルデータブロックを解放して再割り当てするだけです。
ps：カードカタログに本のエントリーがあるからといって、それが棚にあるというわけではありません（チェックアウトされているか、おそらく失われている）。ファイルサイズ0.
pps：ライブラリ内の本の置き忘れは、検索ライブラリを意味します。またはコンピュータ用語では、chkdskまたは修復ディスクです。
UNIXのiノードについて読んだり、バージョン管理システム（ClearCase、TFS、Gitなど）がファイルやディレクトリだけでなくファイルのバージョン、さらにはディレクトリのバージョンを管理する方法を理解することで、より深い理解が得られます。ほとんどの場合、すべてがデータベースに保存され、古典的なディレクトリ構造とファイルとして表示されるようにユーザーに表示されます。
私たちはここでいくつかの素晴らしい答えを持っています - 私はただ絵のバージョンを追加したいと思います（千の言葉とすべてのこと）
これは、ディスクデフラグツールを使って視覚化した場合のNTFSフォーマットのハードドライブの1つです。 MFT（マスターファイルテーブル） はバイオレットで表示されます。
その小さなバイオレットの四角は私のHDに存在するファイルのリストを表しています。大まかに言うと、NTFSディスクの場合、目次は本のためのものです。ページではなく、ディスクの残りの部分の物理的な場所を指しています。1。
サイズが0バイトのファイルは、まったくページがないことを示す目次エントリとして視覚化できます。
エントリはそこにリストされています - しかしページが示されていないので、コンテンツは存在しないと仮定することができます。
1 - 確かに、それはそれより少し複雑です。しかし、セクターマップ、ミラーMFTなどの点は、この質問の範囲外です。
ファイルシステムストアたくさんファイル名、ファイルサイズ、作成時間、アクセス時間、変更時間、作成されたユーザー、ユーザーとグループのアクセス許可、フラグメント、保存するクラスターへのポインターなどのファイルに関する情報ファイル、ハード/ソフトリンク、属性...これらは ファイルメタデータ と呼ばれます。ユーザーがそれらを気にしない（必要としない）ため、それらのメタデータをファイルサイズにカウントするのはなぜですか？彼らは本当にファイルの内容だけを気にします
さらに各ファイルシステムは異なるタイプのメタデータを保存しますディスク上の異なる量のスペースを使用します。たとえば、POSIXアクセス許可はNTFSアクセス許可とは大きく異なり、POSIXにはWindowsには存在しないinode番号もあります。 POSIXファイルシステムでさえ、32ビットブロックアドレスのext3、48ビットのext4、64ビットのBtrfs、128ビットアドレスのZFSなど、さまざまです。では、これらのメタデータをファイルサイズにどのようにカウントしますか？
現在のファイルシステムでメタデータが56バイトを消費する100バイトのファイルを使用した別の例を考えてみましょう。ファイルを別のファイルシステムにコピーすると、128バイトのメタデータが必要になります。ただし、ファイルの内容はまったく同じです、バイト数ファイル内も同じです。そのため、ファイルサイズをシステムでは156バイト、別のシステムでは228バイトと表示すると、非常に混乱し、直感に反します。
ファイルサイズが0の場合、次のようになります。5という単語が書かれた論文があります。そして別の論文では、その上に0という言葉があります。だから0は完全に可能です。
ファイルのメタデータ（作成日時、最終更新日時、ファイル所有者、アクセス許可）はすべて他の場所に格納され、ファイルサイズの一部としては含まれません。
だからこれはそれがどのように動作するかです：
ボリューム上にファイルを作成するとすぐに、NTFS mataファイルに$ MFT（マスターファイルテーブル）というファイルレコードが作成されます。 MFTにはFRS（ファイルレコードセグメント）が存在するため、レコードが表示されます。 NTFSファイルシステムの場合、各ファイルレコードのサイズはデフォルトで1 KBです。ただし、そのスペースは、ファイル内に情報を格納している場合にのみ要求されます。テキストファイルであることを考慮して1文字の「a」を書くだけでも、それがFRSのデフォルトサイズであるため、1 KBのスペースが要求されます。文字 "a"は、そのFRSのデフォルトの名前なしデータストリーム、$ Dataに行きます。これは、ADS（Alternate Data Stream）を持っていない場合、すべてのデータが入る属性です。
あなたが何か質問を思いついたかどうか私に知らせてください。
- NTFS ファイルの増加 の詳細については。
- NTFSメタファイル に関する詳細情報。
簡単な方法で理解してください。ファイルを作成すると、指定したファイル名で識別されるファイルのメモリ位置へのポインタとして機能するディレクトリエントリが生成されます。ディレクトリのサイズは、ポインタを増やしたりファイルを言ったりするにつれて大きくなります。一方、ファイルサイズは、指定された場所、つまりファイル自体の内側にデータを配置する場合にのみ大きくなります。それまではサイズはゼロになります。 :)