write

Section: System Calls (2)
Updated: 2026-02-08
Index JM Home Page roff page
 

名前

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

ライブラリ

標準 C ライブラリ (libc,~-lc)  

書式

#include <unistd.h>

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

説明

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

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

seek 可能なファイル (つまり lseek(2) が適用できるファイル、例えば通常のファイル) では、 書き込みはファイルオフセットから行われ、 ファイルオフセットは実際に書き込みが行われたバイト数分 加算される。ファイルが O_APPEND で open(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.  

返り値

On success, the number of bytes written is returned. On error, -1 is returned, and errno is set to indicate the error.

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).

If count is zero and fd refers to a regular file, then write() may return a failure status if one of the errors below is detected. If no errors are detected, or error detection is not performed, 0 is returned without causing any other effect. If count is zero and fd refers to a file other than a regular file, the results are not specified.  

エラー

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 に接続されたオブジェクトによっては、他のエラーが起こるかもしれない。  

標準規格

POSIX.1-2024.  

歴史

SVr4, 4.3BSD, POSIX.1-2001.

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

注意

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 で規定された効果が互いにアトミックに行われなければならない: ...

Among the APIs subsequently listed are write() and writev(2). And among the effects that should be atomic across threads (and processes) are updates of the file offset. However, before Linux 3.14, this was not the case: if two processes that share an open file description (see open(2)) perform a write() (or writev(2)) at the same time, then the I/O operations were not atomic with respect to updating the file offset, with the result that the blocks of data output by the two processes might (incorrectly) overlap. This problem was fixed in 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)


 

Index

名前
ライブラリ
書式
説明
返り値
エラー
標準規格
歴史
注意
バグ
関連項目

This document was created by man2html, using the manual pages.