スティッキービットがファイルに適用されたとき、元々何をしましたか？
さまざまな場所で、機能nowadaysがディレクトリおよび制限付き削除フラグとして機能します。
AskUbuntuの回答で、回答者は "通常、スティッキービットがディレクトリに適用される" と記述しました。実際、現代のシステムは実際にはファイルに適用しないように見えますが、ずっと前に通常ケースが（実行可能プログラムのイメージ）ディレクトリではなくファイル。 （ファイルでの最近の使用法の不足に関しては、関連する質問があります 現在のファイルシステムではスティッキービットは使用されていません 。）
これは質問を促しました：
過去形に注意してください。これは スティッキービットはどのように機能するのですか？ ではありません。それは、それが当時働いていた方法です。
いいえ、スティッキービットはset-UIDフラグやset-GIDフラグとは異なりました。資格情報を処理するための変更には影響しませんでした。
スティッキービットが行ったことは、プログラムのテキストを「スティッキー」にすることでした。もともと、それは誤称ではありませんでした。
背景：プログラム画像セクションと共有テキスト
本質的には、実行可能ファイル形式（塗りつぶし可能な書籍）の詳細にあまり深く入り込むことなく：プログラムを実行するためにメモリに直接読み込まれるプログラムイメージファイルの部分は、マシンコード、定数、スタートアップで構成されます。 （ゼロで初期化されていない）変数の値、および（何らかの形式で）ゼロで初期化された変数と初期化されていない変数の空白スペース。
これらは「セクション」と呼ばれるコレクションにグループ化され、従来の名前が付けられています。マシンコードと（場合によっては）定数は、プログラムイメージの「テキスト」セクションとしてよく知られているものを形成します。ゼロ以外で初期化された変数は、同様に「データ」セクションです。ゼロで初期化された変数と初期化されていない変数は「bss」です（それ自体が、その背後に完全な民俗の歴史を持つ名前です）。
プロセスにプログラム実行可能イメージファイルがロードされている場合、さまざまな部分（テキスト、データ、およびbss）がイメージファイルの内容から初期化されます。
「テキスト」セクションの特別な点は、マシンコード（および定数）がほとんど常に書き込まれないことです。実行可能イメージファイルが読み込まれたすべての実行プロセスの仮想メモリイメージ全体で、共有になる可能性があります。プログラムテキストを共有できる正確なシナリオはこの回答の範囲外であり、ローダーフィックスアップのべき等やアドレススペースレイアウトのIDなどが含まれます。人々はこの主題についての本も書けるし、書いたこともある。 ☺
共有テキストは、カーネルが採用する最適化です。実行中の単一のプログラムイメージのすべてのインスタンスが独自のメモリイメージを持つ必要がなくなり、まったく同じマシンコード（および定数）の複数のコピーで貴重な物理メモリを消費します。
付箋
しかし、共有されたテキストよりもさらに良いことができます。明らかに、特定の共有テキストプログラムイメージを使用しているプロセスが常に少なくとも1つ実行されている場合、カーネルは、プログラムの新しいインスタンスが実行されるときに、既存の共有テキストセグメントに新しいプロセスの仮想メモリ空間を接続するだけです。中規模システムでは、ほとんどの場合（たとえば）/bin/loginまたは/bin/sh running somewhereのインスタンスが存在するため、ログインプログラムの新しいインスタンスまたはデフォルトのシェルは単純に接続できます。カーネルがすでにメモリにロードしているテキストセグメントのロードされたコピーに。
スティッキーテキストは、このアイデアをプログラムイメージに拡張します現在実行中のプロセスはありません。実行可能イメージファイルがスティッキーテキストとしてマークされている場合、カーネルはそれを使用する最後のプロセスが終了した後もテキストセグメントを保持します。プログラムの別のインスタンスがすぐに実行され、セグメントに再び接続できることを期待して。
初期のUnicesでは、ロードされたスティッキーテキストセグメントは、プロセスがアタッチされていないときにスワップストレージにスワップされていました。 （後でUnicesはswapの使用を中止しました。）saved textという名前で聞いたことがあるかもしれません。
もちろん、プログラムイメージにスティッキーテキストビットを設定することは、慎重に行う必要があります。どのプログラムがその恩恵を受けるかは、マシンが一般的に何のために使用されるかによって異なります。また、現在接続されていないテキストセグメントはカーネルリソースを消費します。つまり、どのシステムでもいくつまで持つことができるかには、実際的な制限があります。したがって、通常はスーパーユーザー権限が必要な操作です。
desuetude
スティッキーテキストの操作の根底にある仮定がたくさんありますが、それはもはや真実ではありません。スワップストレージから事前に作成されたセグメントを読み取ることは、実際の実行可能イメージファイルからの単純なデマンドページングよりも高速であるとは限りません。ファイルシステムのフォーマットは、（順次ではなく）ランダムな読み取りパターンに適しています。デマンドページング自体の出現により、統合キャッシュ、共有ライブラリ検索の違いに起因する非べき等外部フィックスアップ、アドレス空間レイアウトのランダム化などのように、状況が変化します。
実行可能プログラムイメージのスティッキーテキストビットの時代は終わりました。たとえば、1980年代半ばに、実行可能プログラムイメージの明示的なスティッキーテキストマーカーフラグは、4.3BSDの作成者によって廃止されたと見なされていました。
参考文献
- モーリスJ.バッハ（1986）。 NIXオペレーティングシステムの設計。プレンティスホール。 ISBN 9780132017992。