Unixシステムでは、なぜそれらを `read（）`または `write（）`できるように `open（）`と `close（）`ファイルを明示的にしなければならないのですか？

なぜopen()およびclose()Unixファイルシステムの設計に存在しますか？

OSが初めて検出したのread()か、write()呼び出されてopen()通常の動作を実行できなかったのでしょうか？

デニス・リッチーはに言及«Unixのタイムシェアリングシステムの進化»ということopenとclose一緒にread、writeとcreat最初からシステムの右側に存在しました。

私はせずにシステムを推測openし、close私はそれは設計が複雑になると考えているが、想像ではないでしょう。一般に、1つだけでなく複数の読み取り呼び出しと書き込み呼び出しを行いたいと思います。これは、UNIXの起源であるRAMが非常に限られている古いコンピューターで特に当てはまります。現在のファイルの位置を維持するハンドルがあると、これが簡単になります。もしreadまたはwriteハンドルを返すことでした、彼らはペアを返す必要があります-ハンドルと自分の戻りステータス。ペアのハンドル部分は、他のすべての呼び出しには役に立たないため、その配置が厄介になります。カーソルの状態をカーネルに残すことで、バッファリングだけでなく効率を向上させることができます。また、パスルックアップに関連するコストもあります。ハンドルがあると、1回だけ支払うことができます。さらに、UNIXワールドビューの一部のファイルには、ファイルシステムパスさえありません（またはありませんでした-今ではのようになります/proc/self/fd）。

その後、すべてのreadおよびwrite呼び出しは、各操作でこの情報を渡す必要があります。

• ファイルの名前
• ファイルの許可
• 呼び出し元が追加または作成中かどうか
• 呼び出し元がファイルの操作を完了したかどうか（未使用の読み取りバッファーを破棄し、書き込みバッファーが実際に書き込みを終了したことを確認するため）

あなたは独立した考えるかどうかのコールを open、read、writeおよびclose単一目的のI / Oのよりも簡単であることをメッセージがあなたの設計哲学に基づいています。Unix開発者は、すべてを行う単一の操作（またはプログラム）ではなく、さまざまな方法で組み合わせることができる単純な操作とプログラムを使用することを選択しました。

ファイルハンドルの概念は、ファイルシステムの一部ではないものも含めて、「すべてがファイルである」というUNIXの設計上の選択のために重要です。テープドライブ、キーボードとスクリーン（またはテレタイプ！）、パンチカード/テープリーダー、シリアル接続、ネットワーク接続、および（主要なUNIXの発明）「パイプ」と呼ばれる他のプログラムへの直接接続など。

grep特に元のバージョンのような多くの単純な標準UNIXユーティリティを見るopen()とclose()、readand への呼び出しが含まれておらず、and だけが含まれていることがわかりwriteます。ファイルハンドルは、シェルによってプログラムの外部に設定され、起動時に渡されます。そのため、プログラムは、ファイルに書き込むのか別のプログラムに書き込むのかを気にする必要はありません。

同様にopen、ファイル記述子を取得する他の方法があるsocket、listen、pipe、dup、、パイプ経由でファイルディスクリプタを送信するために非常にヒース・ロビンソンのメカニズム：https://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux -ソケット

編集：インダイレクションの層と、これによりO_APPENDが適切に機能する方法を説明する講義ノート。iノードデータをメモリに保持することで、システムが次の書き込み操作のためにそれらを再度フェッチする必要がなくなることに注意してください。

open（）とclose（）はそれぞれハンドルを作成および破棄するため、答えはノーです。特定のアクセスレベルを持つ唯一の呼び出し元であることを保証したい場合があります（たとえば、実際には常に）、予期せずに解析しているファイルに別の呼び出し元が書き込みを行う可能性があるためです未知の状態にあるアプリケーション、または、食事の哲学者の補題などのライブロックまたはデッドロックにつながるアプリケーション。

その考慮がなくても、考慮すべきパフォーマンスへの影響があります。close（）を使用すると、ファイルシステムは（適切な場合または呼び出した場合）占有していたバッファをフラッシュすることができます。これは高価な操作です。インメモリストリームに対する連続した複数の編集は、データセンターに相当する高遅延バルクストレージに散在する世界の半分に存在するファイルシステムに対する、本質的に無関係な複数の読み取り/書き込み/変更サイクルよりもはるかに効率的です。ローカルストレージでも、メモリは通常、バルクストレージよりも桁違いに高速です。

Open（）は、使用中のファイルをロックする方法を提供します。ファイルがOSによって自動的に開かれ、読み取り/書き込みが行われ、再び閉じられた場合、他のアプリケーションがそれらのファイルを操作間で変更するのを止めることはできません。

これは管理が容易ですが（多くのシステムは非排他的なファイルアクセスをサポートしています）、ほとんどのアプリケーションは、開いているファイルが変更されないと想定しています。

ファイルのパスは同じままであると仮定しているときに移動する可能性があるためです。

ファイルシステムへの読み取りと書き込みが可能スキームをバッファリングし、OSのハウスキーピング、低レベルのディスク管理、およびその他の潜在的な行動のホストの多種多様を伴います。行動はそうopen()とclose()、セットアップフード活動の下で、これらのタイプのためとしての役割を果たす。ファイルシステムのさまざまな実装は、必要に応じて高度にカスタマイズでき、呼び出し元のプログラムに対して透過性を維持できます。

OSにオープン/クローズがない場合、with readまたはを使用するとwrite、それらのファイルアクションは、初期化、バッファーのフラッシュ/管理などを毎回実行する必要があります。これは、読み取りと書き込みの繰り返しに課せられる多くのオーバーヘッドです。

Unixのマントラは「物事を行う1つの方法を提供する」、つまり、自由に結合される（再利用可能な）断片に「ファクタリング」することを意味します。つまり、この場合、ファイルハンドルの作成と破棄をその使用から分離します。パイプとネットワーク接続により、後で重要な利点が得られました（これらはファイルハンドルでも操作されますが、他の方法で作成されます）。ファイルハンドルを配布できる（たとえば、それらを子プロセスに "open files"として渡しexec(2)、パイプを介して無関係なプロセスに渡すことも）この方法でのみ可能です。特に、保護されたファイルへの制御されたアクセスを提供する場合。だから、例えば開くことができます/etc/passwd 書き込みのために、それを書き込みのためにそのファイルを開くことを許可されていない子プロセスに渡します（はい、これはばかげた例です。もっとリアルなもので自由に編集してください）。