Linuxでゼロバイトのファイルを作成するコンセプトは何ですか？
次の場合：
touch /tmp/test
そして実行する
ls -la /tmp/
ディレクトリにBytesがあるtestファイルを確認できました。
しかし、オペレーティングシステムはBytesの概念をどのように処理しますか。素人の言葉で言えば：
0バイトはメモリがないため、何も作成されません。
ファイルの作成、必須またはする必要があります少なくとも特定のメモリが必要です。正しい？
ファイルは（おおよそ）3つの独立したものです。
- 「iノード」は、ファイルの所有者、権限、および実際にデータを含むディスク上のブロックのリストを追跡するメタデータ構造です。
- そのiノードを指す1つまたは複数のディレクトリエントリ（ファイル名）
- データ自体の実際のブロック
空のファイルを作成すると、iノードとそのiノードを指すディレクトリエントリのみが作成されます。スパースファイル（dd if=/dev/null of=sparse_file bs=10M seek=1）。
既存のファイルへのハードリンクを作成するときは、同じiノードを指す追加のディレクトリエントリを作成するだけです。
ここでは簡略化しましたが、あなたはそのアイデアを理解しました。
touchはinodeを作成し、ls -iまたはstatは、iノードに関する情報を表示します。
$ 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: -
testは0ブロックを使用することに注意してください。表示されたデータを格納するために、iノードはいくつかのバイトを使用します。これらのバイトはiノードテーブルに格納されます。 ext2ページで inode構造の例 を探します。
ls（または、stat(2)システムコール）は、ファイルのcontentsのサイズを示します。ファイルシステムが簿記に必要とするスペースの量はその一部ではありません。実装の詳細として、これは一般的にプログラムするものではありませんすべき気にしたり、知っていることさえあります。実装の詳細を表示すると、ファイルシステムの抽象化があまり役に立たなくなります。
ファイル自体はスペースを占有しませんが、ファイルシステムはファイル名、場所、アクセス権などを格納して占有します。
簡単な答え：それはそのように定義されているからです。
より長い答え：一部の操作は概念的に単純であるため、そのように定義されています。
- ファイルに20文字の「A」が含まれている場合、すべての「A」を削除すると、ファイルは20バイト短くなります。 "AAAAAAAAAAAAAAAAAAAA"だけで構成されるファイルに対する同じ操作は、消失するファイルの特殊なケースを処理する必要があります。
- より実用的には、テキストファイルの最後の行を削除するには、特別なケースが必要になります。
- 定期的にバックアップを作成するテキストエディターは、ユーザーが最後の行を削除し、昼食に行き、その後戻って別の行を追加する可能性がある状況に対処するために、特別なケースのコードが必要になります。その間に他のユーザーがその名前のファイルを作成した場合、さらに複雑になります。
さらに多くのことができます。*エラーログファイルは空になりがちで、エラーが発生した場合にのみ入力されます。 *発生したエラーの数を確認するには、ログファイルの行数をカウントします。ログファイルが空の場合、エラーの数はゼロであり、これは完全に理にかなっています。 *場合によっては、関連するすべてのテキストがファイル名に含まれているファイルが表示されることがあります。 this-is-the-logging-directory。これにより、熱心な管理者がインストール後に空のディレクトリを削除することを防ぎ、プログラムまたはユーザーが誤ってファイルを作成して、プログラムが後でディレクトリを表示したいというバグも防ぎます。 gitプログラム（および他のプログラム）は空のディレクトリを無視する傾向があり、プロジェクト/管理者/ユーザーが、（まだ）有用なコンテンツがなくても、ディレクトリが存在するというレコードを保持したい場合は、 emptyまたはempty.directoryという名前の空のファイル。
操作が複雑になることはありません。
- ファイルの連結：これは、空のファイルを含む何もしないことです。
- ファイル内の文字列の検索：これは、「ファイルが検索語よりも短い場合、検索語を含めることはできない」という標準的なケースでカバーされています。
- ファイルからの読み取り：プログラムは、期待した結果が得られる前にファイルの終わりに到達する必要があるため、長さがゼロのファイルの場合、プログラマーは余分な考慮を必要としません。 -最初からファイル。
ファイルの場合、「どこかに記録されたファイルがあります」という側面（iノードまたはファイル名、あるいはその両方）が上記の考慮事項に加えられますが、空のファイルが役に立たない場合、ファイルシステムはそれを行いません。
一般に、ファイル名に関連するものを除いて、上記の理由はすべてシーケンスに適用されます。特に文字列は、文字のシーケンスです。長さがゼロの文字列は、プログラム内では一般的です。文字列は、意味がない場合、ユーザーレベルでは通常許可されていません。ファイル名は文字列であり、ほとんどのファイルシステムでは、空の文字列をファイル名として使用できません。内部的には、フラグメントからファイル名を作成するとき、プログラムはフラグメントの1つとして空の文字列を持っている可能性があります。
最も単純な類推を使用：
たとえば、ファイルを水1杯と比較してみましょう。
「touch/tmp/test」は、水が入っていない空のグラスを作成するのとよく似ています。ガラスは空なので、サイズはゼロです。しかし、ガラスは存在します。
ファイルシステムの用語では、グラスはメタデータですが、グラスの内容はデータです。メタデータには、以前の投稿で述べたように、あらゆる種類のものが含まれています。
サイズがゼロのファイルが役立つ場合があります。 1つの例は、それらをパンくずリストとして使用することです。その存在は、ある種の状態を示すために使用できます（つまり、ファイルが存在する場合は、何かを実行し、存在しない場合は無視します）。
このように考えてください。プログラムがサーバーに送信されたSQLクエリを追跡しているとしましょう。プログラムは要求をプレーンテキストファイルに記録しているが、まだ要求が記録されていないことを示す必要があります。それはどのように見えるべきですか？ /var/log/acme-sql-server/queries.logのサイズがゼロのファイルである必要があります。このようにして、ロギングがいつ開始されたか（ファイルの作成時刻）、最後に更新された時期（つまり、ファイルが作成された時期）、記録されたクエリの数（ファイル内の改行の数= 0）、誰がロギングを行っているかを把握できます。 （Acme SQL Server）。このような場合、特定の場所に存在する空のファイルの概念があると便利です。