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

名前

       write - ファイルディスクリプター (file descriptor) に書き込む

書式

       #include <unistd.h>

       ssize_t write(int fd, const void *buf, size_t count);

説明

       write()  は、 buf から始まるバッファーから、ファイルディスクリプター fd が参照するファイル
       へ、最大 count バイトを書き込む。

       書き込まれるバイト数は count よりも小さくなることがある。 例えば、書き込み対象の物理メディ
       アに十分な領域がない場合、  リソース上限  RLIMIT_FSIZE に達した場合 (setrlimit(2)  参照)、
       count バイト未満の書き込みが行われた後で  呼び出しがシグナルハンドラーにより割り込まれた場
       合、 などである。 (pipe(7)  も参照のこと。)

       seek  可能なファイル  (つまり lseek(2)  が適用できるファイル、例えば通常のファイル) では、
       書き込みはファイルオフセットから行われ、  ファイルオフセットは実際に書き込みが行われたバイ
       ト数分  加算される。ファイルが O_APPENDopen(2)  された場合、ファイルオフセットは書き込
       み前に ファイルの末尾に設定される。 ファイルオフセットの調整と書き込み操作はアトミックな処
       理として 実行される。

       POSIX  は write()  が行なわれた後に実行した read(2)  が 新しいデータを返すことを要求してい
       る。 全てのファイルシステムが POSIX 準拠ではない点に注意すること。

       According  to  POSIX.1,  if   count   is   greater   than   SSIZE_MAX,   the   result   is
       implementation-defined; see NOTES for the upper limit on Linux.

返り値

       成功すると、書き込まれたバイト数が返される。エラーの場合、  -1 が返り、 errno にエラーの原
       因を示す値が設定される。

       Note that a successful write()  may transfer fewer than count bytes.  Such partial  writes
       can  occur  for  various reasons; for example, because there was insufficient space on the
       disk device to write all of the requested bytes,  or  because  a  blocked  write()   to  a
       socket,  pipe,  or  similar  was  interrupted by a signal handler after it had transferred
       some, but before it had transferred all of the requested bytes.  In the event of a partial
       write,  the  caller  can  make another write()  call to transfer the remaining bytes.  The
       subsequent call will either transfer further bytes or may result in an error (e.g., if the
       disk is now full).

       count が 0 で、 fd が通常のファイル (regular file) を参照している場合、 write() は後述のエ
       ラーのいずれかを検出した場合、失敗を返すことがある。  エラーが検出されなかった場合、もしく
       はエラー検出が実行されなかった場合、  0 が返され、他に何の影響も与えない。 count が 0 で、
       fd が通常のファイル以外のファイルを参照している場合、 その結果は規定されていない。

エラー

       EAGAIN ファイルディスクリプター   fd    がソケット以外のファイルを参照していて、    非停止
              (nonblocking) モード (O_NONBLOCK)  に設定されており、書き込みを行うと停止する状況に
              ある。 O_NONBLOCK フラグの詳細は open(2) を参照。

       EAGAIN または EWOULDBLOCK
              ファイルディスクリプター fd がソケットを参照していて、非停止  (nonblocking)  モード
              (O_NONBLOCK)   に設定されており、書き込みを行うと停止する状況にある。  POSIX.1-2001
              は、この場合にどちらのエラーを返すことも認めており、 これら 2  つの定数が同じ値を持
              つことも求めていない。 したがって、移植性が必要なアプリケーションでは、両方の可能性
              を 確認すべきである。

       EBADF  fd が有効なファイルディスクリプターでないか書き込みのためにオープン (open) されてい
              ない。

       EDESTADDRREQ
              fd  が、 connect(2)  を使って通信相手のアドレスが設定されていないデータグラムソケッ
              トを 参照している。

       EDQUOT fd が参照するファイルを含むファイルシステムのディスクブロックのユーザークォータの上
              限に達している。

       EFAULT buf がアクセス可能なアドレス空間の外にある。

       EFBIG  実装定義の最大ファイルサイズまたはプロセスのファイルサイズ制限を 超えてファイルに書
              き込もうとした。 または許可されたオフセット値の限界を超えた先の位置に  書き込もうと
              した。

       EINTR  何のデータも書かない間にシグナルにより割り込まれた (interrupt)。 signal(7)  参照。

       EINVAL fd  が書き込みが不適切なオブジェクトを参照している。  もしくは、ファイルが O_DIRECT
              フラグを指定してオープンされているが、 buf に指定されたアドレス、 count  に指定され
              た値、 ファイルオフセットのいずれかのアラインメントが不適切である。

       EIO    A low-level I/O error occurred while modifying the inode.  This error may relate to
              the write-back of data written by an earlier write(), which may have been issued to
              a  different  file  descriptor  on  the  same  file.  Since Linux 4.13, errors from
              write-back come with a promise that they may be reported  by  subsequent.   write()
              requests,  and will be reported by a subsequent fsync(2)  (whether or not they were
              also reported by write()).  An alternate cause of EIO on networked  filesystems  is
              when  an  advisory lock had been taken out on the file descriptor and this lock has
              been lost.  See the Lost locks section of fcntl(2)  for further details.

       ENOSPC fd によって参照されるファイルを含むデバイス (device) に十分な空きがない。

       EPERM  操作が file seal により禁止されている。 fcntl(2)  参照。

       EPIPE  fd がパイプ (pipe) かソケット (socket) に接続されており、  その反対側  (読み込み側)
              がクローズ  (close) されている。 これが発生した場合には、書き込みを行なうプロセスは
              SIGPIPE  シグナル  (signal)も受ける。   (したがって、プログラムがこのシグナルを捕獲
              (catch)、停止 (block)、無視 (ignore)  した場合のみ、write の返り値を参照できる。)

       fd に接続されたオブジェクトによっては、他のエラーが起こるかもしれない。

準拠

       SVr4, 4.3BSD, POSIX.1-2001.

       SVr4 では write が割り込まれると、データが書き込まれる直前ではなく、 その時点で EINTR が返
       る。

注意

       The types size_t and ssize_t are, respectively, unsigned and  signed  integer  data  types
       specified by POSIX.1.

       A successful return from write()  does not make any guarantee that data has been committed
       to disk.  On some filesystems, including NFS, it does not even guarantee  that  space  has
       successfully been reserved for the data.  In this case, some errors might be delayed until
       a future write(), fsync(2), or even close(2).  The only way to be sure is to call fsync(2)
       after you are done writing all your data.

       write()  が 1 バイトも書き込まないうちにシグナルハンドラーにより割り込まれた場合、 write()
       はエラー EINTR で失敗する。 1バイトでも書き込んだ後で割り込まれた場合には、 write()   は成
       功し、書き込んだバイト数を返す。

       On   Linux,  write()   (and  similar  system  calls)  will  transfer  at  most  0x7ffff000
       (2,147,479,552) bytes, returning the number of bytes actually transferred.  (This is  true
       on both 32-bit and 64-bit systems.)

       An  error return value while performing write()  using direct I/O does not mean the entire
       write has failed. Partial data may be written and the data at the file offset on which the
       write()  was attempted should be considered inconsistent.

バグ

       POSIX.1-2008/SUSv4   セクション   XSI   2.9.7  ("Thread  Interactions  with  Regular  File
       Operations") によると、

           以下のすべての関数では、        通常ファイルもしくはシンボリックリンクに対する操作では
           POSIX.1-2008 で規定された効果が互いにアトミックに行われなければならない: ...

       この後に書かれている API の中に write() と writev(2) である。 スレッド(やプロセス) 間でア
       トミックに適用することが求められる効果の一つとして、 ファイルオフセットの更新がある。 しか
       しながら、  バージョン  3.14 より前の Linux では、 この限りではない。 オープンファイル記述
       (open file description) を共有する 2 つのプロセスが同時に write() (や writev(2))  を実行し
       た場合、  この I/O 操作ではファイルオフセットの更新に関してはアトミックではなく、 2 つのプ
       ロセスから出力されるデータブロックが (間違って) 重なる可能性がある。 この問題は Linux 3.14
       で修正された。

関連項目

       close(2),  fcntl(2), fsync(2), ioctl(2), lseek(2), open(2), pwrite(2), read(2), select(2),
       writev(2), fwrite(3)

この文書について

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