Provided by: manpages-ja-dev_0.5.0.0.20161015+dfsg-1_all bug

名前

       fcntl - ファイルディスクリプターの操作を行う

書式

       #include <unistd.h>
       #include <fcntl.h>

       int fcntl(int fd, int cmd, ... /* arg */ );

説明

       fcntl()   は、オープンされたファイルディスクリプター  fd  に関して下記の操作を行う。操作は
       cmd によって決まる:

       fcntl() はオプションとして第三引き数をとることができる。 第三引き数が必要  かどうかは  cmd
       により決まる。必要な引き数の型は cmd 名の後ろの括弧内で 指定されている (ほとんどの場合、必
       要な型は int であり、この引き数を表すの に arg という名前を使っている)。引き数が必要ない場
       合には void が指定さ れている。

       下記のいくつかの操作は特定のバージョンの  Linux  カーネルでのみサポートされている。 ホスト
       カーネルが特定の操作をサポートしているかを確認する推奨の方法は、 fcntl() を所望の cmd 値で
       呼び出し、 EINVAL で失敗するかを検査することである。 EINVAL が返った場合、カーネルがこの値
       を認識していないことを示す。

   ファイルディスクリプターの複製
       F_DUPFD (int)
              利用可能なファイルディスクリプターのうち、 arg 以上で最小のものを探し、 fd のコピー
              とする。これは別の形の dup2(2) である。 dup2(2)  では指定されたディスクリプターが使
              われる点が違う。

              成功すると、新しいディスクリプターが返される。

              詳細は dup(2)  を参照のこと。

       F_DUPFD_CLOEXEC (int; Linux 2.6.24 以降)
              F_DUPFD と同様だが、それに加えて複製されたディスクリプターに対して close-on-exec フ
              ラグをセットする。 このフラグを指定することで、プログラムは FD_CLOEXEC フラグをセッ
              トするために fcntl()  の F_SETFD 操作を追加で行う必要がなくなる。  このフラグがなぜ
              有用かについては、 open(2)  の O_CLOEXEC の説明を参照のこと。

   ファイルディスクリプターフラグ
       以下のコマンドを使って、ファイルディスクリプターに関連するフラグ  を操作することができる。
       現在のところ、定義されているフラグは一つだけである:  FD_CLOEXEC  (close-on-exec  フラグ)。
       FD_CLOEXEC ビットが 0 なら、ファイルディスクリプターは execve(2)  を行ってもオープンされた
       ままだが、そうでない場合はクローズされる。

       F_GETFD (void)
              ファイルディスクリプターフラグを読み出す。 arg は無視される。

       F_SETFD (int)
              ファイルディスクリプターフラグに arg で指定した値を設定する。

       マルチスレッドプログラムでは、 fcntl() の F_SETFD を使って close-on-exec  フラグを設定する
       のと同時に、 別のスレッドで execve(2) と fork(2) を実行することは、競合条件次第では、 その
       ファイルディスクリプターが子プロセスで実行されるプログラムに意図せず見えてしまうという危険
       性がある。  詳細とこの問題への対処法については open(2) の O_CLOEXEC フラグの議論を参照のこ
       と。

   ファイル状態フラグ
       オープンファイル記述 (open file description) には、 ファイル記述毎に設定される状態フラグが
       いくつかある。これらのフラグは  open(2)  によって初期化され、 fcntl(2)  により変更すること
       もできる。これらは、 (dup(2), fcntl(F_DUPFD), fork(2)  などで)  複製されたファイルディスク
       リプター同士は  同じオープンファイル記述を参照する。 そのため、 同じファイル状態フラグが共
       有される。

       ファイル状態フラグとその意味は open(2)  で説明されている。

       F_GETFL (void)
              ファイルのアクセスモードとファイル状態フラグを取得する。 arg は無視される。

       F_SETFL (int)
              ファイル状態フラグに arg で指定された値を設定する。 arg  のうち、ファイルのアクセス
              モード   (O_RDONLY,  O_WRONLY,  O_RDWR)   とファイル作成フラグ  (すなわち  O_CREAT,
              O_EXCL, O_NOCTTY, O_TRUNC)  に関するビットは無視される。 Linux では、このコマンドで
              変更できるのは  O_APPEND,  O_ASYNC,  O_DIRECT, O_NOATIME, O_NONBLOCK フラグだけであ
              る。フラグ O_DSYNC, O_SYNC を変更することはできない。下記の「バグ」を参照。

   アドバイザリーレコードロック
       Linux は昔からある (「プロセスに関連付けられる」) UNIX のレコードロックを実装している。 こ
       のレコードロックは POSIX で標準化されている。 Linux 固有のより良い動作を行うロックについて
       は、下記のオープンファイル記述ロックの議論を参照のこと。

       F_SETLK, F_SETLKW, F_GETLK は、レコードロックの獲得/解放/テストのために使用する  (レコー
       ドロックは、バイト範囲ロック、ファイルセグメントロック、ファイル領域ロックとも呼ばれる)。
       三番目の引き数 lock は、以下に示すフィールドを含む構造体へのポインターである (フィールドの
       順序は関係なく、構造体に他のフィールドがあってもよい)。

           struct flock {
               ...
               short l_type;    /* Type of lock: F_RDLCK,
                                   F_WRLCK, F_UNLCK */
               short l_whence;  /* How to interpret l_start:
                                   SEEK_SET, SEEK_CUR, SEEK_END */
               off_t l_start;   /* Starting offset for lock */
               off_t l_len;     /* Number of bytes to lock */
               pid_t l_pid;     /* PID of process blocking our lock
                                   (set by F_GETLK and F_OFD_GETLK) */
               ...
           };

       この構造体の l_whence, l_start, l_len フィールドで、ロックを行いたいバイト範囲を指定する。
       ファイルの末尾より後ろのバイトをロックすることはできるが、  ファイルの先頭より前のバイトを
       ロックすることはできない。

       l_start   はロックを行う領域の開始オフセットである。   その意味は  l_whence  により異なる:
       l_whenceSEEK_SET の場合はファイルの先頭からのオフセット、 l_whenceSEEK_CUR  の場合
       は現在のファイルオフセットからのオフセット、 l_whenceSEEK_END の場合はファイルの末尾か
       らのオフセットと解釈される。 後ろの2つの場合には、 ファイルの先頭より前にならない範囲で、
       l_start に負の値を指定することができる。

       l_len はロックしたいバイト数を示す。 l_len が正の場合、ロックされるバイト範囲は l_start 以
       上 l_start+l_len-1 以下となる。 l_len に 0 を指定した場合は特別な意味を持つ: l_whence  and
       l_start で指定される位置からファイルの末尾までの全てのバイトをロックする (ファイルがどんな
       に大きくなったとしてもファイルの末尾までロックする)。

       POSIX.1-2001 では、負の値の l_len をサポートする実装を認めている (必須ではない)。 l_len が
       負の場合、ロックされるバイト範囲は  l_start+l_len  以上  l_start-1 以下となる。 この動作は
       カーネル 2.4.21 以降および 2.5.49 以降の Linux で サポートされている。

       l_type フィールドは、ファイルに対して読み出しロック (F_RDLCK)  と書き込みロック  (F_WRLCK)
       のどちらを  設定するかを指定する。 ファイルのある領域に対して、読み出しロック (共有ロック)
       を保持できる プロセス数に制限はないが、書き込みロック (排他ロック) を保持できる のは一つの
       プロセスだけである。排他ロックを設定すると、(共有ロックか 排他ロックにかかわらず) 他のロッ
       クは何も設定できない。  一つのプロセスは、ファイルのある領域に対して一種類のロックしか保持
       できない。 新規のロックがロックが設定されている領域に対して適用されると、既存のロック は新
       規のロックの種別に変換される (新規のロックで指定されたバイト範囲が既存ロックの範囲と一致す
       る場合以外では、 変換の過程で既存のロックの分割、縮小、結合が行われることがある)。

       F_SETLK (struct flock *)
              (l_typeF_RDLCKF_WRLCK の場合は) ロックの獲得を、 (F_UNLCK の場合は) ロック
              の解放を、 flock 構造体のフィールド l_whence, l_start, l_len で指定された範囲のバイ
              トに対して行う。   指定されたロックが他のプロセスが設定しているロックと衝突する場合
              は、 -1 を返し、 errnoEACCESEAGAIN を設定する。 (この場合に返されるエラーは
              実装により異なる。 そのため、 POSIX では移植性が必要なアプリケーションでは、 これら
              の両方のエラーをチェックすることが必要としている。)

       F_SETLKW (struct flock *)
              F_SETLK と同様だが、こちらではそのファイルに対して衝突するロックが 適用されていた場
              合に、そのロックが解放されるのを待つ点が異なる。 待っている間にシグナルを受けた場合
              は、システムコールは中断され、 (シグナルハンドラーが戻った直後に) 返り値 -1  を返す
              (また errnoEINTR が設定される; signal(7)  参照)。

       F_GETLK (struct flock *)
              このコールの呼び出し時には、  lock にはそのファイルに適用しようとするロックに関する
              情報が入っている。 ロックを適用できる場合には、 fcntl()  は実際にはロックを行わず、
              構造体 lockl_type フィールドに F_UNLCK を返し、 他のフィールドは変更しない。

              違う種別のロックが  (一つもしくは複数) 適用されていてロックを適用できないような場合
              には、 fcntl() は、  原因となったロックの一つについての詳細を、  lock  のフィールド
              l_type,  l_whence, l_start, l_len で返す。 衝突するロックが昔からある (プロセスに関
              連付けられる) レコードロックの場合、 l_pid フィールドにロックを保持しているプロセス
              の  PID  が設定される。 衝突するロックがオープンファイル記述ロックの場合、 l_pid に
              -1 が設定される。 呼び出し元がその内容を参照した時点では、 返された情報はすでに古い
              ものとなっている可能性がある点に注意すること。

       読み出しロックを適用するには、  fd は読み出し用にオープンされていなければならない。 書き込
       みロックを適用するには、 fd は書き込み用にオープンされていなければならない。  読み書き両方
       のロックを適用するには、読み書き両用で ファイルをオープンしなければならない。

       F_SETLKW  でロックを適用する際、  カーネルはデッドロックの検出を行う。  2 つ以上のプロセス
       が、  他のプロセスが保持するロックにより互いにブロックされるようなロック要求を行っているか
       を検査する。 例えば、 プロセス A があるファイルのバイト 100 に対して書き込みロックを保持し
       ていて、 プロセス B がバイト 200 に対して書き込みロックを保持しているとする。 各プロセスが
       F_SETLKW    を使って他のプロセスによるすでにロックされているバイトをロックしようとすると、
       デッドロック検出がない場合、 両方のプロセスが無限に停止することになる。 カーネルはこのよう
       なデッドロックを検出すると、 停止していたロック要求の一つをエラー EDEADLK ですぐに失敗させ
       る。  このエラーを受け取ったアプリケーションは、  必要なロックを再度獲得しようとする前に、
       他のアプリケーションが実行できるように自分が保持するロックのいくつかを解放する必要がある。
       3 つ以上のプロセスが関連する循環するデッドロックも検出される。  ただし、  カーネルのデッド
       ロック検出アルゴリズムには制限がある点に注意すること。 「バグ」を参照。

       ろコードロックは F_UNLCK で明示的に削除されるだけでなく、 そのプロセスが終了した際には自動
       的に解放される。

       レコードのロックは fork(2)  で作成された子プロセスには継承されないが、 execve(2)  の前後で
       は保存される。

       stdio(3)   ではバッファーリングが行われるので、 stdio 関連の関数ではレコードのロックの使用
       は回避される; 代わりに read(2)  や write(2)  を使用すること。

       上記で説明したレコードロックはプロセスと関連付けられる (以下で説明するオープンファイル記述
       ロックと異なる点である)。 そのため、 残念ながら以下のようなことが起こる。

       *  プロセスがロックが適用されているファイルを参照しているファイルディスクリプターの「いず
          れか」をクローズした場合、   そのファイルに対するそのプロセスのすべてのロックが解放され
          る。  この動作はまずい。 あるプロセスが /etc/passwd/etc/mtab といったファイルにロッ
          クを適用しているときに、  あるライブラリ関数が何かの理由で同じファイルを  open,   read,
          close すると、そのファイルへのロックが失われることになる。

       *  1  つのプロセス内のスレッドはロックを共有する。 言い換えると、 マルチスレッドのプログラ
          ムで、 レコードロックを使って、 複数のスレッドが同時に 1 つのファイルの同じ領域にアクセ
          スしないようにすることはできないということだ。

       オープンファイル記述ロックを使うとこれらの問題が解決できる。

   オープンファイル記述ロック (非 POSIX)
       オープンファイル記述ロックはバイト範囲に対するアドバイザリーロックで、  ほとんどの点で上述
       の昔からあるレコードロックと等価である。 このロック種別は Linux 固有であり、 Linux 3.15 以
       降で利用できる。 オープンファイル記述の説明は open(2) を参照。

       2  つのロック種別の主な違いは、 昔からあるレコードロックはプロセスに関連付けられるのに対し
       て、  オープンファイル記述ロックはロックが獲得されるオープンファイル記述に関連付けられる点
       である。 この動作は flock(2) で獲得されるロックによく似ている。 結果として (昔からあるアド
       バイザリーレコードロックと違い)、 オープンファイル記述ロックは fork(2) (や CLONE_FILES  付
       きの  clone(2))  の前後で継承され、  ファイルのクローズ時に解放されるのではなく、 オープン
       ファイル記述の最後のクローズ時にのみ自動的に解放される。

       オープンファイル記述ロックは常に昔からあるレコードロックと競合する。 たとえ、 ロックが同じ
       プロセスによって同じファイルディスクリプターに対して行われたとしてもである。

       同じオープンファイル記述経由 (同じファイルディスクリプター経由や fork(2), dup(2), fcntl(2)
       F_DUPFD などで作成されたファイルディスクリプターの複製経由) で適用されたオープンファイル記
       述ロックは常に互換性がある。 つまり、 すでにロックされている領域に対して新しいロックが適用
       された場合、 既存のロックは新しいロック種別に変換される。 (上記で説明した通り、 このような
       変換の結果、 既存のロックの分割、 縮小、 結合が行われることがある。)

       一方、 異なるオープンファイル記述経由で獲得されると、 オープンファイル記述ロックは互いに競
       合する。  したがって、  マルチスレッドプログラムのスレッドは、  各スレッドがそれぞれ自分で
       open(2) を実行し、 得られたファイルディスクリプター経由でロックを適用することで、 オープン
       ファイル記述ロックを使って一つのファイル領域えのアクセスを同期させることができる。

       昔からあるレコードロックの場合と同様、 fcntl() の第 3 引き数 lockflock  構造体へのポイ
       ンターである。  昔からあるレコードロックと違い、 下記で説明するコマンドを使う際には、 この
       構造体のフィールド l_pid に 0 を設定しなければならない。

       オープンファイル記述ロックで使用できるコマンドは、    昔からあるロックのコマンドと同じであ
       る。

       F_OFD_SETLK (struct flock *)
              (l_typeF_RDLCKF_WRLCK  の場合は) オープンファイル記述のロックの獲得を、
              (F_UNLCK の場合は) オープンファイル記述のロックの解放を、 flock  構造体のフィールド
              l_whence,  l_start, l_len で指定された範囲のバイトに対して行う。 指定されたロックが
              他のプロセスが設定しているロックと衝突する場合は、 -1 を返し、 errnoEAGAIN を設
              定する。

       F_OFD_SETLKW (struct flock *)
              F_OFD_SETLK と同様だが、こちらではそのファイルに対して衝突するロックが 適用されてい
              た場合に、そのロックが解放されるのを待つ点が異なる。 待っている間にシグナルを受けた
              場合は、システムコールは中断され、  (シグナルハンドラーが戻った直後に) 返り値 -1 を
              返す (また errnoEINTR が設定される; signal(7) 参照)。

       F_OFD_GETLK (struct flock *)
              このコールの呼び出し時には、 lock  にはそのファイルに適用しようとするロックに関する
              情報が入っている。 ロックを適用できる場合には、 fcntl()  は実際にはロックを行わず、
              構造体 lockl_type フィールドで F_UNLCK を返し、 他のフィールドは変更しない。 違
              う種別のロックが  (一つもしくは複数) 適用されていてロックを適用できないような場合に
              は、  原因となったロックの一つについての詳細が   lock   で返される。   詳細は上記の
              F_GETLK を参照。

       現在の実装では、  オープンファイル記述ロクではデッドロックの検出は行われない。 (これがプロ
       セスと関連付けられるレコードロックとは異なる点である。    プロセスと関連付けられるレコード
       ロックではカーネルはデッドロックの検出を行う。)

   強制ロック (mandatory locking)
       警告:  Linux  の強制ロックの実装は信頼性に欠けるものである。  下記の「バグ」の節を参照のこ
       と。

       デフォルトでは、 昔からある (プロセスに関連付けられる) レコードロックも、 オープンファイル
       記述のろコードロックも、   アドバイザリーロックである。   アドバイザリーロックに強制力はな
       く、協調して動作するプロセス間でのみ有効である。

       両方のタイプのロックも強制ロックにすることもできる。  強制ロックは全てのプロセスに対して効
       果がある。  あるプロセスが互換性のない強制ロックが適用されたファイル領域に対して  (read(2)
       や write(2)  により)  互換性のないアクセスを実行しようとした場合、  アクセスの結果は  その
       ファイルのオープンファイル記述で    O_NONBLOCK    フラグが有効になっているかにより決まる。
       O_NONBLOCK フラグが有効になっていないときは、ロックが削除されるか、 ロックがアクセスと互換
       性のあるモードに変換されるまで、 システムコールは停止 (block) される。 O_NONBLOCK フラグが
       有効になっているときは、システムコールはエラー EAGAIN で失敗する。

       強制ロックを使用するためには、ロック対象のファイルが含まれるファイルシステム  と、ロック対
       象のファイル自身の両方について、強制ロックが有効になっていなけれ  ばならない。ファイルシス
       テムについて強制ロックを有効にするには、  mount(8)   に  "-o  mand"   オプションを渡すか、
       mount(2)  に MS_MANDLOCK フラグを指定する。ファイルについて強制ロックを有効にするには、 そ
       のファイルのグループ実行許可 (group execute permission) を無効とし、 かつ set-group-ID  許
       可ビットを有効にする (chmod(1)  と chmod(2)  を参照)。

       強制ロックは POSIX では規定されていない。 他のいくつかのシステムでも強制ロックはサポートさ
       れているが、 強制ロックをどのようにして有効にするかの詳細はシステムより異なる。

   シグナルの管理
       F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_GETSIG, F_SETSIG は、I/O  が利用可能になっ
       たことを示すシグナルを管理するために使用される。

       F_GETOWN (void)
              ファイルディスクリプター fd のイベントに対するシグナル SIGIO および SIGURG を受けて
              いるプロセスのプロセスID かプロセスグループを (関数の結果として) 返す。  プロセスID
              は正の値として返される。  プロセスグループID は負の値として返される (下記のバグの章
              を参照)。 arg は無視される。

       F_SETOWN (int)
              ファイルディスクリプター fd のイベント発生を知らせるシグナル SIGIOSIGURG を受け
              るプロセスの  プロセス  ID またはプロセスグループID を arg で指定された ID に設定す
              る。 プロセスID は正の値として指定し、 プロセスグループID  は負の値として指定する。
              ほとんどの場合、呼び出し元プロセスは所有者として自分自身を指定する  (つまり  arggetpid(2) を指定する)。

              fcntl()  の F_SETFL コマンドを使用してファイルディスクリプターに O_ASYNC 状態フラグ
              を設定した場合には、そのファイルディスクリプターへの  入出力が可能になる度に  SIGIO
              シグナルが送られる。 F_SETSIGSIGIO  以外の別のシグナルの配送を受けられるように
              するのにも使うことができる。  許可 (permission) のチェックで失敗した場合には、 シグ
              ナルは黙って捨てられる。

              F_SETOWN により指定された所有者のプロセス (またはプロセスグループ) に  シグナルを送
              る際には、  kill(2) に書かれているのと同じ許可のチェックが行われる。 このとき、シグ
              ナルを送信するプロセスは F_SETOWN を使ったプロセスである  (但し、下記の「バグ」の章
              を参照のこと)。

              ファイルディスクリプターがソケットを参照している場合は、   F_SETOWN  を使用して、ソ
              ケットに帯域外 (out-of-band) データが届いた時に SIGURG シグナルを配送する相手を選択
              することもできる  (SIGURG が送られた場合には select(2) がソケットが「特別な状態」に
              あると報告することだろう)。

              バージョン 2.6.11 以前の 2.6.x カーネルでは、以下に示す動作であった。

                     スレッドグループをサポートしているスレッドライブラリ (例えば NPTL) を 使って
                     動作しているマルチスレッドプロセスで  F_SETSIG に 0 以外の値を指定した場合、
                     F_SETOWN  に正の値を渡すと、その意味が違ってくる:   プロセス全体を示すプロセ
                     スID ではなく、プロセス内の特定の スレッドを示すスレッドID と解釈される。 し
                     たがって、 F_SETSIG を使う場合には、きちんと結果を受け取るには、 F_SETOWN に
                     渡す値を  getpid(2)  ではなく gettid(2) の返り値にする必要があるだろう。 (現
                     状の Linux スレッド実装では、メインスレッドのスレッドID は  そのスレッドのプ
                     ロセスID   と同じである。つまり、   シグナルスレッドのプログラムではこの場合
                     gettid(2)  と getpid(2) は全く同じように使うことができる。)   ただし、注意す
                     べき点として、この段落で述べたことは、  ソケットの帯域外データが届いたときに
                     生成される SIGURG シグナルにはあてはまらない。  このシグナルは常にプロセスか
                     プロセスグループに送られ、  送信先は F_SETOWN に渡された値にしたがって決めら
                     れる。

              上記の動作は、Linux 2.6.12  で図らずも削除され、  元に戻されない予定である。  Linux
              2.6.32 以降で、特定のスレッド宛にシグナル SIGIOSIGURG を送るには F_SETOWN_EX を
              使うこと。

       F_GETOWN_EX (struct f_owner_ex *) (Linux 2.6.32 以降)
              直前の F_SETOWN_EX 操作で定義された現在のファイルディスクリプターの所有者設定  を返
              す。情報は arg が指す構造体に格納されて返される。構造体は以下の通りである。

                  struct f_owner_ex {
                      int   type;
                      pid_t pid;
                  };

              type フィールドは、 F_OWNER_TID , F_OWNER_PID , F_OWNER_PGRP のいずれか一つの値とな
              る。 pid フィールドは、スレッド ID、プロセス ID、プロセスグループ ID を  表す正の整
              数である。詳細は F_SETOWN_EX を参照。

       F_SETOWN_EX (struct f_owner_ex *) (Linux 2.6.32 以降)
              この操作は F_SETOWN と同様の処理を行う。 この操作を使うと、I/O が利用可能になったこ
              とを示すシグナルを、   特定のスレッド、プロセス、プロセスグループに送ることができる
              ようになる。   呼び出し元は、   arg   経由でシグナルの配送先を指定する。   argf_owner_ex 構造体へのポインターである。 type フィールドは以下のいずれかの値を取り、
              この値により pid がどのように解釈されるかが規定される。

              F_OWNER_TID
                     スレッド ID が pid で指定された値のスレッドにそのシグナルを送る (スレッド ID
                     は clone(2)  や gettid(2)  の呼び出しで返される値である)。

              F_OWNER_PID
                     ID が pid で指定された値のプロセスにそのシグナルを送る。

              F_OWNER_PGRP
                     ID が pid  で指定された値のプロセスグループにそのシグナルを送る。  (F_SETOWN
                     と異なり、プロセスグループ ID には正の値を指定する点に注意すること。)

       F_GETSIG (void)
              入力や出力が可能になった場合に送るシグナルを   (関数の結果として)  返す。  値ゼロは
              SIGIO を送ることを意味する。 (SIGIO を含む) 他の値はいずれも、 SIGIO の代わりに送る
              シグナル番号を表す。 後者の場合、シグナルハンドラーを SA_SIGINFO フラグ付きで設定す
              れば、ハンドラーで追加の情報を得ることができる。 arg は無視される。

       F_SETSIG (int)
              入力や出力が可能になった場合に送るシグナルを arg に指定された値に設定する。  値ゼロ
              は  SIGIO を送ることを意味する。 (SIGIO を含む) 他の値はいずれも、 SIGIO の代わりに
              送るシグナル番号を表す。 後者の場合、シグナルハンドラーを SA_SIGINFO フラグ付きで設
              定すれば、 ハンドラーで追加の情報を得ることができる。

              F_SETSIG  にゼロ以外の値を設定し、シグナルハンドラーに  SA_SIGINFO フラグを設定する
              と、 (sigaction(2) を参照) I/O イベントに関する追加の情報が siginfo_t  構造体でシグ
              ナルハンドラーへ渡される。 si_code フィールドが示すシグナルの原因が SI_SIGIO である
              場合、 si_fd フィールドにはイベントに対応するファイルディスクリプターが入っている。
              それ以外の場合は、どのファイルディスクリプターが利用可能かを示す情報は ないので、ど
              のファイルディスクリプターで I/O が可能かを判断するためには 通常の機構  (select(2),
              poll(2), O_NONBLOCK を設定した read(2)  など) を使用しなければならない。

              リアルタイムシグナル (値が SIGRTMIN 以上) を選択している場合は、 同じシグナル番号を
              持つ複数の I/O イベントがキューに入ることがある (キューに入れるかどうかは利用可能な
              メモリーに依存している)。  上記と同様、 SA_SIGINFO が設定されている場合、シグナルハ
              ンドラーのための追加の情報が得られる。

              以下の点に注意すること。 Linux では一つのプロセスに対してキューに入れられるリアルタ
              イム  シグナルの数に上限が設けられており (getrlimit(2)  と signal(7)  を参照)、この
              上限に達するとカーネルは SIGIO シグナルを配送する。この SIGIO  シグナルは、指定され
              たスレッドではなくプロセス全体に送られる。

       これらの機構を使用することで、ほとんどの場合で select(2)  や poll(2)  を使用せずに完全な非
       同期 I/O を実装することができる。

       O_ASYNC の使用方法は BSD と Linux  に特有である。  POSIX.1  で規定されている  F_GETOWNF_SETOWN  の使用方法は、ソケットに対する SIGURG シグナルとの組み合わせだけである (POSIX は
       SIGIO シグナルは規定していない)。 F_GETOWN_EX, F_SETOWN_EX, F_GETSIG, F_SETSIG は Linux 固
       有である。POSIX   には、同様のことを行うために、非同期   I/O  と  aio_sigevent  構造体があ
       る。Linux では、GNU C ライブラリ (Glibc) の一部として これらも利用可能である。

   リース (leases)
       (Linix 2.4 以降で利用可能)  F_SETLEASE は、 fd  が参照するオープンファイル記述に対して新し
       いリースを設定するのに使用される。 F_GETLEASE は、 fd が参照するオープンファイル記述に対し
       て設定されている 現在のリースを取得するのに使用される。 ファイルのリースにより、  あるプロ
       セス   ("lease   breaker")  がそのファイルディスクリプターが参照  しているファイルに対して
       open(2)  や truncate(2) を行おうとした際に、リースを保持しているプロセス ("lease  holder")
       へ (シグナルの配送による) 通知が行われるという機構が提供される。

       F_SETLEASE (int)
              arg の内容に基いてファイルのリースの設定、削除を行う。整数 arg には以下の値が指定で
              きる:

              F_RDLCK
                     読み出しリースを取得する。これにより、  そのファイルが書き込み用にオープンさ
                     れたり、ファイルが切り詰められた場合に、  呼び出し元のプロセスに通知が行われ
                     るようになる。  読み出しリースを設定できるのは、読み出し専用でオープンされて
                     いる ファイルディスクリプターに対してのみである。

              F_WRLCK
                     書き込みリースを取得する。これにより、  (読み出し用か書き込み用にかかわらず)
                     そのファイルがオープンされたり、  ファイルが切り詰められた場合に、呼び出し元
                     のプロセスに通知が行われるようになる。  書き込みリースは、そのファイルに対す
                     るオープンされたファイルディスクリプターが 他にない場合にのみ設定できる。

              F_UNLCK
                     そのファイルからリースを削除する。

       リースはオープンファイル記述に対して関連付けられる (open(2)  参照)。 つまり、 (fork(2)  や
       dup(2) などにより作成された) ファイルディスクリプターの複製は同じリースを参照し、 複製も含
       めたどのファイルディスクリプターを使ってもこのリースを変更したり   解放したりできる。   ま
       た、これらのファイルディスクリプターのいずれかに対して  F_UNLCK 操作が明示的に実行された場
       合や、すべてのファイルディスクリプターが 閉じられた場合にも、リースは解放される。

       リースの取得は通常のファイル (regular file) に対してのみ可能である。  非特権プロセスがリー
       スを取得できるのは、UID  (所有者) がプロセスの ファイルシステム UID と一致するファイルに対
       してだけである。 CAP_LEASE  ケーパビリティを持つプロセスは任意のファイルに対してリースを取
       得できる。

       F_GETLEASE (void)
              ファイルディスクリプター fd に対して設定されているリースの種別を取得する。 F_RDLCK,
              F_WRLCK, F_UNLCK のいずれかが返される。 F_RDLCK,  F_WRLCK  はそれぞれ、読み出しリー
              ス、書き込みリースが設定されていることを示し、 F_UNLCK はリースが何も設定されていな
              いことを示す。 arg は無視される。

       あるプロセス ("lease breaker") が F_SETLEASE で設定されたリースと矛  盾するような  open(2)
       や truncate(2) を実行した場合、 そのシステム コールはカーネルによって停止され、 カーネルは
       lease holder にシグナル (デフォルトでは SIGIO) を送って通知を行う。 lease holder  はこのシ
       グ  ナルを受信したときにはきちんと対応すべきである。 具体的には、別のプロセ スがそのファイ
       ルにアクセスするための準備として 必要な後片付け  (例えば、  キャッシュされたバッファーのフ
       ラッシュ) を すべて行ってから、そのファイル のリースの削除または格下げを行う。リースを削除
       をするには、 argF_UNLCK を指定して F_SETLEASE を実行する。lease holder がファイル に書
       き込みリースを保持していて、 lease breaker が読み出し用にそのファイ ルをオープンしている場
       合、 lease holder が保持しているリースを読み出し リースに格下げすれば 十分である。これをす
       るには、 argF_RDLCK を指定して F_SETLEASE を実行する。

       If  the  lease  holder fails to downgrade or remove the lease within the number of seconds
       specified in /proc/sys/fs/lease-break-time, then the kernel forcibly removes or downgrades
       the lease holder's lease.

       いったん lease break が開始されると、 lease holder が自発的にそのリース の格下げか削除を行
       うか、lease  break  timer  の満了後にカーネルが強制的に   リースの格下げか削除を行うまで、
       F_GETLEASE  は対象となるリースの型を  返す  (リースの型は  F_RDLCKF_UNLCK のどちらであ
       り、lease breaker と互換性のある型となる)。

       一度リースの削除か格下げが自発的もしくは強制的に行われると、 lease breaker  がまだシステム
       コールを再開していない場合には、  カーネルが  lease breaker のシステムコールの続行を許可す
       る。

       lease breaker が実行した open(2)  や truncate(2)  が停止中にシグナルハンドラーにより中断さ
       れた場合、  そのシステムコールは EINTR エラーで失敗するが、上で述べた他の処理は そのまま行
       われる。 open(2)  や truncate(2)  が停止中に lease breaker がシグナルにより kill  された場
       合、   上で述べた他の処理はそのまま行われる。   lease   breaker   が  open(2)   を呼ぶ際に
       O_NONBLOCK フラグを指定した場合、そのシステムコールは  EWOULDBLOCK  エラーで直ちに失敗する
       が、上で述べた他の処理はそのまま行われる。

       lease holder への通知に使われるデフォルトのシグナルは SIGIO だが、 fcntl()  の F_SETSIG コ
       マンドで変更することができる。  F_SETSIG  コマンドが実行され  (SIGIO  を指定された場合も含
       む)、 SA_SIGINFO フラグ付きでシグナルハンドラーが設定されている場合には、 ハンドラーの第二
       引き数として siginfo_t 構造体が渡され、この引き数の si_fd フィールドには別のプロセスがアク
       セスしたリース設定済みファイルの  ディスクリプターが入っている (この機能は複数のファイルに
       対してリースを設定する場合に有用である)。

   ファイルやディレクトリの変更の通知 (dnotify)
       F_NOTIFY (int)
              (Linux 2.4 以降)  fd で参照されるディレクトリか、その中にあるファイルに変更があった
              場合に  通知を行う。どのイベントを通知するかは  arg で指定する。 arg はビットマスク
              で、以下のビットの 0個以上の論理和をとったものを指定する。

              DN_ACCESS   ファイルへのアクセスがあった (read(2), pread(2), readv(2)  や同様のシス
                          テムコール)
              DN_MODIFY   ファイルの内容が変更された     (write(2),     pwrite(2),     writev(2),
                          truncate(2), ftruncate(2) や同様のシステムコール)
              DN_CREATE   ファイルが作成された  (open(2),   creat(2),   mknod(2),   mkdir(2),   "
                          "link(2), symlink(2), このディレクトリへの rename(2))
              DN_DELETE   ファイルが削除   (unlink)   された   (unlink(2),   別のディレクトリへの
                          rename(2), rmdir(2))
              DN_RENAME   ディレクトリ内でのファイル名の変更があった (rename(2))
              DN_ATTRIB   ファイル属性が変更された (chown(2), chmod(2), utime(2), utimensat(2) や
                          同様のシステムコール)

              (上記の定義を利用するには、どの        ヘッダーファイルをインクルードするより前に、
              _GNU_SOURCE 機能検査マクロを定義しなければならない。)

              ディレクトリの変更通知は通常「一回限り (one-shot)」であり、  アプリケーション側でそ
              の後さらに通知を受信したい場合は  再登録しなければならない。 argDN_MULTISHOT が
              含まれていた場合には、 変更通知は明示的に解除されるまで有効状態が継続する。

              F_NOTIFY 要求は積算されていく。つまり、 arg  で指定されたイベントがすでにモニタされ
              ている  イベント集合に加算される形になる。 すべてのイベントの通知を無効にするには、
              arg に 0 を指定して F_NOTIFY を呼び出す必要がある。

              通知はシグナルの配送で行われる。 デフォルトのシグナルは SIGIO  だが、  fcntl()   の
              F_SETSIG コマンドで変更することができる。 (SIGIO はキューイングされない標準のシグナ
              ルの一つである点に注意。 リアルタイムシグナルを使うように変更すると、  複数の通知が
              そのプロセス宛のキューに入ることがあることを意味する。)            後者の場合には、
              (SA_SIGINFO フラグ付きでシグナルハンドラーが設定されている場合には)  ハンドラーの第
              二引き数として  siginfo_t 構造体が渡され、この構造体の si_fd フィールドには通知の行
              われたファイルディスクリプターが入っている  (この機能は複数のディレクトリに対して通
              知を設定する場合に有用である)。

              特に DN_MULTISHOT を使う場合は、通知にはリアルタイムシグナルを使うべきである。 それ
              は、リアルタイムシグナルを使うことで、複数の通知をキューに入れる ことができるからで
              ある。

              注意:  新しくアプリケーションを書く際には、(カーネル 2.6.13 以降で利用可能となった)
              inotify インターフェースを使用すべきである。 inotify はファイルシステムイベントの通
              知を取得するための ずっと優れたインターフェースである。 inotify(7)  を参照。

   パイプの容量の変更
       F_SETPIPE_SZ (int; Linux 2.6.35 以降)
              fd が参照するパイプの容量を少なくとも arg バイトに変更する。 非特権プロセスは、パイ
              プの容量として、 システムのページサイズと  /proc/sys/fs/pipe-max-size  で定義される
              上限値 (proc(5) 参照) の間の任意の値を設定できる。 パイプの容量をページサイズよりも
              小さな値に設定しようとした場合は、 暗黙のうちにページサイズに切り上げられる。  非特
              権プロセスがパイプの容量を /proc/sys/fs/pipe-max-size で定義 された上限より大きな値
              に設定しようとした場合は、エラー EPERM が 発生する。特権プロセス  (CAP_SYS_RESOURCE
              ケーパビリティを持つ  プロセス) はこの上限を上書きできる。 パイプにバッファーを割り
              当てる場合、実装側の都合に応じて、 カーネルは arg  よりも大きな容量を割り当ててもよ
              い。  実際に設定された大きさが関数の返り値として返される。 パイプの容量を現在データ
              を格納するのに使用されているバッファーの   サイズよりも小さくしようとした場合は、エ
              ラー EBUSY が発生する。

       F_GETPIPE_SZ (void; Linux 2.6.35 以降)
              fd が参照するパイプの容量を (関数の結果として) 返す。

   File Sealing
       file seal は指定されたファイルで許可される操作の集合を制限する。 ファイルに設定される seal
       毎に対応する操作の集合が規定されており、      それ以降のそのファイルに対する対応する操作は
       EPERM で失敗する。 このようなファイルは sealed (seal が適用されている) と呼ばれる。 デフォ
       ルトの seal の集合は、適用されるファイルやファイルシステムに依存する。 file seal  の概要、
       その目的、 サンプルコードについては memfd_create(2) を参照。

       現在のところ  tmpfs ファイルシステムだけが sealing をサポートしている。 他のファイルシステ
       ムでは、 seal に関連する fcntl(2) の操作はすべて EINVAL を返す。

       seal は inode の属性である。 したがって、 同じ inode  を参照するすべてのオープンされたファ
       イルディスクリプターは、  同じ  seal の集合を共有する。 さらに、 seal は削除することはでき
       ず、 追加のみ可能である。

       F_ADD_SEALS (int; Linux 3.17 以降)
              ビットマスク引き数 arg で指定された seal を、 ファイルディスクリプター fd  が参照す
              る inode の seal の集合に追加する。 一度追加した seal を削除することはできない。 こ
              の呼び出しが成功すると、 seal はただちにカーネルにより適用される。 現在の seal の集
              合に  F_SEAL_SEAL  (下記参照)  が含まれている場合、 この呼び出しは EPERM で拒否され
              る。 すでに設定されている seal を追加した場合、 F_SEAL_SEAL  がまだ設定されていない
              場合は  no-op  (何もしない) となる。 seal を設定するには、 ファイルディスクリプター
              fd が書き込み可能でなければならない。

       F_GET_SEALS (void; Linux 3.17 以降)
              (関数の結果として) fd が参照する inode の seal の現在の集合を返す。 seal が何も設定
              されていない場合、  0 が返される。 ファイルが sealing をサポートしていない場合、 -1
              が返され、 errnoEINVAL が設定される。

       以下の seal が利用できる。

       F_SEAL_SEAL
              この seal が設定されると、  これ以降の F_ADD_SEALS を指定した fcntl(2) の呼び出しは
              すべて EPERM で失敗する。 したがって、 この seal を設定すると seal の集合自身の変更
              を防止できる。 ファイルの最初の seal の集合に F_SEAL_SEAL が含まれていた場合、 結果
              的に seal の集合が定数になりロックされることになる。

       F_SEAL_SHRINK
              この  seal  が設定されると、  設定されたファイルのサイズを小さくできなくなる。 この
              seal は open(2) の O_TRUNC フラグに影響する。 truncate(2) と ftruncate(2)  について
              も同様である。  対象のファイルのサイズを小さくしようとした場合、 これらの呼び出しは
              EPERM で失敗する。 ファイルサイズを増やすことはこの場合でも可能である。

       F_SEAL_GROW
              この seal が設定されると、 設定されたファイルのサイズを増やせなくなる。  この  seal
              はファイルの末尾を超えての write(2) や truncate(2), ftruncate(2), fallocate(2) に影
              響する。 対象のファイルのサイズを大きくしようとした場合、 これらの呼び出しは  EPERM
              で失敗する。 ファイルサイズが変わらない場合、 小さくなる場合は、 これらの呼び出しは
              そのまま動作する。

       F_SEAL_WRITE
              この seal が設定されていると、 ファイルの内容を変更できない。  ファイルのサイズを縮
              小したり伸張したりすることは可能で許可されている。  したがって、 この seal は通常は
              他の  seal  のいずれかと組み合わせて使用される。   この   seal   は   write(2)   と
              fallocate(2)  (FALLOC_FL_PUNCH_HOLE フラグとの組み合わせの場合のみ) に影響する。 こ
              の seal が設定されると、 これらの呼び出しは EPERM で失敗する。 また、 mmap(2)  によ
              る新しい書き込み可能な共有メモリーマッピングの作成も EPERM で失敗する。

              fcntl(2) の F_ADD_SEALSF_SEAL_WRITE を設定しようとした場合、 書き込み可能な共有
              マッピングが存在すると EBUSY で失敗する。 このようなマッピングは、 この seal を追加
              する前にアンマップしなければならない。  また、 ファイルに対して処理待ちの非同期 I/O
              操作 (io_submit(2) がある場合、 処理されていない書き込みは破棄される。

返り値

       成功した場合の返り値は操作の種類により違う:

       F_DUPFD  新しいディスクリプターを返す。

       F_GETFD  ファイルディスクリプターフラグの値

       F_GETFL  ファイル状態フラグの値

       F_GETLEASE
                ファイルディスクリプターに対して保持されているリースの種別を返す。

       F_GETOWN ディスクリプターの所有者を返す。

       F_GETSIG 読み込みや書き出しが可能になった時に送られるシグナルの値、もしくは 伝統的な SIGIO
                動作の場合にはゼロを返す。

       F_GETPIPE_SZ, F_SETPIPE_SZ
                パイプの容量。

       F_GET_SEALS
                fd が参照する inode に設定されている seal を示すビットマスク。

       他の全てのコマンド
                0 を返す。

       エラーの時は -1 が返され、 errno に適切な値が設定される。

エラー

       EACCESEAGAIN
              他のプロセスが保持しているロックによって操作が禁止されている。

       EAGAIN そのファイルは他のプロセスによってメモリーマップされているため、 操作が禁止されてい
              る。

       EBADF  fd がオープンされたファイルディスクリプターではない。

       EBADF  cmdF_SETLK または  F_SETLKW  だったが、対象のファイルディスクリプターのオープン
              モードが 必要となるロックの型にマッチしていない。

       EBUSY  cmdF_SETPIPE_SZ で、 arg で指定されたパイプの新しい容量がパイプが、 現在パイプ
              にあるデータを格納するのに使用されているバッファー容量よりも小さい。

       EBUSY  cmdF_ADD_SEALS で、 argF_SEAL_WRITE が含まれており、 fd  が参照するファイル
              に対する書き込み可能な共有マッピングが存在する。

       EDEADLK
              指定された F_SETLKW コマンドを実行した場合にはデッドロックになることが検出された。

       EFAULT lock が利用可能なアドレス空間の外部にある。

       EINTR  cmdF_SETLKWF_OFD_SETLKW で、 操作がシグナルにより割り込まれた。 signal(7)
              参照。

       EINTR  cmdF_GETLK, F_SETLK, F_OFD_GETLK, F_OFD_SETLK で、 操作がシグナルにより割り込ま
              れた  (signal(7)  参照)。 F_GETLKF_SETLK の場合、ロックを確認したり取得したりす
              る前にシグナルによって割り込まれた。 これはたいていリモートのファイルをロックする場
              合 (例えば NFS 上でロックする場合) に起こる。 しかしローカルでも起こる場合がある。

       EINVAL カーネルが認識しない値が cmd で指定された。

       EINVAL cmdF_ADD_SEALS で、 arg に認識できない seal を示すビットが含まれている。

       EINVAL cmdF_ADD_SEALSF_GET_SEALS で、 fd が参照している inode が格納されているファ
              イルシステムが sealing をサポートしていない。

       EINVAL cmdF_DUPFD で、 arg が負か、もしくは許される最大値よりも大きい (getrlimit(2) の
              RLIMIT_NOFILE の議論を参照)。

       EINVAL cmdF_SETSIG で、 arg が許可されたシグナル番号ではない。

       EINVAL cmdF_OFD_SETLK, F_OFD_SETLKW, F_OFD_GETLK のいずれかで、 l_pid に 0 が指定され
              なかった。

       EMFILE cmdF_DUPFDで、 プロセスがすでに最大数までファイルディスクリプターをオープンして
              いる。

       ENOLCK オープンされているロックの数が多過ぎて、ロックテーブルがいっぱいである。     または
              remote locking protocol (例えば NFS 上のロック) が失敗した。

       ENOTDIR
              F_NOTIFYcmd に指定されたが、 fd がディレクトリを参照していない。

       EPERM  追加専用属性が設定されたファイルの O_APPEND フラグをクリアしようと試みた。

       EPERM  cmdF_ADD_SEALS だが、 fd が書き込み用にオープンされていないか、  ファイルの現在
              の seal の集合にすでに F_SEAL_SEAL が含まれている。

準拠

       SVr4,  4.3BSD,  POSIX.1-2001.   POSIX.1-2001  で規定されている操作は、  F_DUPFD,  F_GETFD,
       F_SETFD, F_GETFL, F_SETFL, F_GETLK, F_SETLK, F_SETLKW だけである。

       F_GETOWNF_SETOWN は POSIX.1-2001 で規定されている。 (これら定義するには、  _BSD_SOURCE
       を定義するか、 _XOPEN_SOURCE を 500 以上の値で定義するか、 _POSIX_C_SOURCE を 200809L 以上
       の値で定義するか、 のいずれが必要である。)

       F_DUPFD_CLOEXEC は POSIX.1-2008 で規定されている。  (これら定義するには、  _POSIX_C_SOURCE
       を 200809L 以上の値で定義するか、 _XOPEN_SOURCE を 700 以上の値で定義すること。)

       F_GETOWN_EX,   F_SETOWN_EX,  F_SETPIPE_SZ,  F_GETPIPE_SZ,  F_GETSIG,  F_SETSIG,  F_NOTIFY,
       F_GETLEASE, F_SETLEASE は Linux 固有である (これらの定義を有効にするには _GNU_SOURCE  マク
       ロを定義すること)。

       F_OFD_SETLK,   F_OFD_SETLKW,   F_OFD_GETLK   は   Linux  固有だが  (これらの定義を得るには
       _GNU_SOURCE を定義しなければならない)、 POSIX.1 の次のバージョンに含めようという活動が進め
       られている。

       F_ADD_SEALSF_GET_SEALS は Linux 固有である。

注意

       エラーの際の返り値が dup2(2)  と F_DUPFD では異なっている。

   ファイルロック
       元々の  Linux の fcntl() システムコールは (flock 構造体で) 大きな ファイルオフセットを扱え
       るように設計されていなかった。 その結果、Linux 2.4 で  fcntl64()  システムコールが追加され
       た。  この新しいシステムコールは、ファイルのロックに flock64 という別の 構造体を利用し、こ
       れに対応するコマンドとして F_GETLK64, F_SETLK64, F_SETLKW64 を使用する。 しかし、 glibc を
       使うアプリケーションではこれらの詳細を無視することが  できる。 glibc の fcntl のラッパー関
       数は新しいシステムコールが 利用できる場合はそれを利用するようになっているからである。

       エラーの際の返り値が dup2(2)  と F_DUPFD では異なっている。

   レコードロック
       カーネル 2.0 以降では、 flock(2)  と fcntl()  が設定するロック種別の間に相互作用はない。

       システムによっては、   struct   flock    に上記以外のフィールドがあるものもある    (例えば
       l_sysid)。 はっきりと言えることは、ロックを保持しているプロセスが別のマシンに存在 する場合
       には、 l_pid だけはあまり役にたたないだろうということである。

       元々の Linux の fcntl() システムコールは (flock 構造体で) 大きな  ファイルオフセットを扱え
       るように設計されていなかった。  その結果、Linux  2.4 で fcntl64() システムコールが追加され
       た。 この新しいシステムコールは、ファイルのロックに flock64 という別の  構造体を利用し、こ
       れに対応するコマンドとして F_GETLK64, F_SETLK64, F_SETLKW64 を使用する。 しかし、 glibc を
       使うアプリケーションではこれらの詳細を無視することが できる。 glibc の fcntl  のラッパー関
       数は新しいシステムコールが 利用できる場合はそれを利用するようになっているからである。

   レコードロックと NFS
       Linux  3.12 より前では、 NFSv4 クライアントが一定時間サーバーと通信がなかった場合 (90 秒間
       通信がない場合と定義されている)、   クライアントが気付かずにロックを失い再獲得する場合があ
       る。 (通信がなくなったみなす時間は NFSv4 leastime と呼ばれる。 Linux NFS サーバーでは、 こ
       の値は /proc/fs/nfsd/nfsv4leasetime を見て決定される。  このファイルの値の単位は秒であり、
       このファイルのデフォルト値は 90 である。) この状況では潜在的にデータ破壊が起こる危険性があ
       る。  通信がなかった間に他のプロセスがロックを獲得しファイル入出力を行う場合があるからであ
       る。

       Linux  3.12 以降、 NFSv4 クライアントがサーバーと通信がなかった場合、 ロックを持っていると
       「思っている」プロセスがそのファイルに入出力を行うと失敗する。  そのプロセスがそのファイル
       をいったんクローズし再オープンするまでは入出力は失敗する。            カーネルパラメーター
       nfs.recover_lost_locks を 1 に設定すると、 Linux 3.12 より前の動作にすることができる。  こ
       の場合、 サーバーとの通信が再確立された場合、 クライアントがは失われたロックを回復しようと
       する。 データ破壊が起こる危険性があるため、 このパラメーターはデフォルトでは 0  (無効)  に
       なっている。

バグ

   F_SETFL
       F_SETFL を使って、 フラグ O_DSYNCO_SYNC の状態を変更することはできない。これらのフラグ
       の状態を変更しようとした場合には、黙って無視される。

   F_GETOWN
       いくつかのアーキテクチャー (特に i386) における Linux システムコールの慣習  のため以下の制
       限が存在する。 F_GETOWN が返す (負の) プロセスグループID が -1 から -4095 の範囲に入った場
       合、 glibc  はこの返り値をシステムコールでエラーが起こったと間違って解釈してしまう。  つま
       り、  fcntl() の返り値は -1 となり、 errno には (正の) プロセスグループID が設定されること
       になる。Linux 固有の F_GETOWN_EX ではこの問題を回避できる。 glibc バージョン  2.11  以降で
       は、glibc  では F_GETOWN_EX を使って F_GETOWN を実装することで、カーネルの F_GETOWN の問題
       を見えないようにしている。

   F_SETOWN
       Linux 2.4 以前では、非特権プロセスが F_SETOWN を使って、ソケットのファイルディスクリプター
       の所有者に  呼び出し元以外のプロセス  (やプロセスグループ)  を指定すると  発生するバグがあ
       る。この場合、 呼び出し元が所有者として指定したプロセス (やプロセスグループ) に シグナルを
       送る許可を持っていたとしても、 fcntl()  が -1 を返し errnoEPERM を設定することがある。
       このエラーが返ったにもかかわらず、ファイルディスクリプターの所有者  は設定され、シグナルは
       その所有者に送られる。

   デッドロックの検出
       F_SETLKW     要求を処理する際にカーネルが使用するデッドロック検出アルゴリズムは、    false
       negative になる場合 (デッドロックを検出できず、 デッドロックになったプロセスは無限に停止す
       る)  も  false  positive になる場合 (デッドロックがない場合でも EDEADLK エラーとなる) もあ
       る。 例えば、 カーネルは依存関係の検索を行うロックの深さを  10  ステップに限定しているが、
       このためこれよりも長い循環するデッドロックは検出されない。  また、 clone(2) の CLONE_FILES
       フラグを使って作成された 2 つ以上のプロセスが (カーネルにとって)  衝突するように見えるロッ
       クを適用した場合、 カーネルはデッドロックを誤って検出する。

   強制ロック (mandatory locking)
       Linux の強制ロックの実装は、 競合条件下で強制ロックが不完全になるような場合がある。 ロック
       と重なって実行された write(2) の呼び出しは強制ロックが獲得された後にもデータを変更すること
       ができる。 ロックと重なって実行された read(2) の呼び出しは強制ロックが獲得された後になって
       行われたデータの変更を 検出することができる。 同様の競合条件が強制ロックと mmap(2)  の間に
       も存在する。それゆえ、強制ロックに頼るのはお薦めできない。

関連項目

       dup2(2), flock(2), open(2), socket(2), lockf(3), capabilities(7), feature_test_macros(7)

       Linux     カーネルソースの    Documentation/filesystems/    ディレクトリ内の    locks.txt,
       mandatory-locking.txt, dnotify.txt (以前のカーネルでは、これらのファイルは  Documentation/
       ディレクトリ直下にあり、 mandatory-locking.txtmandatory.txt という名前であった)

この文書について

       この  man ページは Linux man-pages プロジェクトのリリース 3.79 の一部 である。プロジェクト
       の説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。