Linuxでゼロバイトのファイルを作成する概念は何ですか？

次のことを行う場合：

touch /tmp/test

そして、実行します

ls -la /tmp/

ディレクトリに0バイトのtestファイルが表示されました。

しかし、オペレーティングシステムは0バイトの概念をどのように処理しますか。素人の言葉で言えば：

0バイトはまったくメモリではないため、何も作成されません。

ファイルの作成必須または必要があり、少なくとも右、特定のメモリを必要？

ファイルは（大体）3つの別個のものです。

• 「inode」。ファイルの所有者、権限、および実際にデータを含むディスク上のブロックのリストを追跡するメタデータ構造。
• そのiノードを指す1つ以上のディレクトリエントリ（ファイル名）
• データ自体の実際のブロック

空のファイルを作成すると、iノードとそのiノードを指すディレクトリエントリのみが作成されます。スパースファイルについても同じです（dd if=/dev/null of=sparse_file bs=10M seek=1）。

既存のファイルへのハードリンクを作成するときは、同じiノードを指す追加のディレクトリエントリを作成するだけです。

ここでは簡単に説明しましたが、アイデアはわかります。

touch作成するinodeをし、ls -iまたはstatiノードに関する情報を表示します。

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

test0ブロックを使用していることに注意してください。表示されたデータを保存するために、iノードはいくつかのバイトを使用します。これらのバイトはiノードテーブルに格納されます。iノード構造の例については、ext2ページを参照してください。

ls（または、stat(2)システムコール）は、ファイルの内容のサイズを示します。ファイルシステムがブックキーピングのためにどれだけのスペースを必要とするかは、その一部ではありません。また、実装の詳細としては、一般的にプログラムが気にする必要のあるものではありません。実装の詳細を表示すると、ファイルシステムの抽象化の有用性が低くなります。

ファイル自体はスペースを占有しませんが、ファイルシステムはファイル名、場所、ファイルへのアクセス権などを保存します。

簡単な答え：それはそのように定義されているからです。

長い回答：一部の操作は概念的に単純であるため、そのように定義されています。

• ファイルに20文字の「A」が含まれ、すべての「A」を削除すると、ファイルは20バイト短くなります。「AAAAAAAAAAAAAAAAAAAAAA」だけで構成されたファイルに対する同じ操作では、消失ファイルの特殊なケースを処理する必要があります。
• 実際には、テキストファイルの最後の行を削除する場合は、特別なケースが必要になります。
• 定期的にバックアップを作成するテキストエディターは、ユーザーが最後の行を削除し、昼食に行き、戻って別の行を追加する可能性がある状況に対処するために、特別なケースのコードが必要です。その間に他のユーザーがその名前でファイルを作成すると、さらに複雑になります。

さらに多くのことができます：*エラーログファイルは空で作成される傾向があり、エラーが発生した場合にのみ満たされる。*発生したエラーの数を調べるには、ログファイルの行数を数えます。ログファイルが空の場合、エラーの数はゼロであり、完全に理にかなっています。*時々、関連するすべてのテキストがファイル名に含まれているファイルが表示されますthis-is-the-logging-directory。これにより、過剰な管理者がインストール後に空のディレクトリを削除することを防ぎます。また、プログラムやユーザーが誤ってディレクトリを表示したいファイルを誤って作成するバグを防ぎます。gitプログラム（その他）は空のディレクトリを無視する傾向があり、プロジェクト/管理者/ユーザーがディレクトリが存在するという記録を持っているしたい場合には有用なコンテンツ（まだ）を持っていないにも関わらず、あなたは、名前の空のファイルを見ることができますemptyまたはempty.directory。

より複雑になる操作はありません。

• ファイルの連結：これは、空のファイルを使用した単なる操作ではありません。
• ファイル内の文字列の検索：これは、「ファイルが検索語より短い場合、検索語を含めることはできません」という標準的なケースでカバーされています。
• ファイルからの読み取り：プログラムは、期待どおりの結果が得られる前にファイルの終わりを押す必要があるため、長さゼロのファイルの場合は、プログラマーにとって余計な思考は必要ありません。最初からファイル。

ファイルの場合、「どこかに記録されたファイルがあります」という側面（inodeやファイル名）が上記の考慮事項に優先しますが、空のファイルが役に立たない場合、ファイルシステムはそれを行いません。

一般に、ファイル名に関連するものを除く上記の理由はすべて、シーケンスに適用されます。最も顕著なのは文字列であり、文字列は文字列です。長さゼロの文字列はプログラム内では一般的です。文字列は通常、意味をなさない場合はユーザーレベルで許可されません。ファイル名は文字列であり、ほとんどのファイルシステムではファイル名として空の文字列を許可しません。内部的には、フラグメントからファイル名を作成するとき、プログラムはフラグメントの1つとして空の文字列を持つ場合があります。

最も単純なアナロジーを使用して：

ファイルをたとえばコップ1杯の水と比較してみましょう。

「touch / tmp / test」は、水が入っていない空のガラスを作成するのに非常によく似ています。ガラスは空なので、サイズはゼロです。しかし、ガラスは存在します。

ファイルシステムの用語では、ガラスはメタデータであり、ガラスの内容はデータです。メタデータには、以前の投稿で述べたようにあらゆる種類のものが含まれています。

サイズがゼロのファイルが便利です。1つの例は、それらをブレッドクラムとして使用することです。そこでは、単なる存在を使用して何らかの状態を示すことができます（つまり、ファイルが存在する場合：次に何かを行い、そうでない場合：無視）。

このように考えてください。サーバーに送信されたSQLクエリをプログラムが追跡しているとします。プログラムは、要求をプレーンテキストファイルに記録していることを示したいが、要求はまだ記録されていない。それはどのように見えるべきですか？でサイズがゼロのファイルであると主張します/var/log/acme-sql-server/queries.log。そうすれば、ロギングの開始時（ファイルの作成時間）、最終更新時（作成時）、記録されたクエリの数（ファイル内の改行数= 0）、および誰がロギングを行っているかを把握できます。 （Acme SQL Server）。このような場合、特定の場所に存在する空のファイルの概念を使用すると便利です。