1 .\" This manpage is Copyright (C) 1992 Drew Eckhardt;
2 .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson.
3 .\" and Copyright (C) 2007 Michael Kerrisk <mtk.manpages@gmail.com>
5 .\" %%%LICENSE_START(VERBATIM)
6 .\" Permission is granted to make and distribute verbatim copies of this
7 .\" manual provided the copyright notice and this permission notice are
8 .\" preserved on all copies.
10 .\" Permission is granted to copy and distribute modified versions of this
11 .\" manual under the conditions for verbatim copying, provided that the
12 .\" entire resulting derived work is distributed under the terms of a
13 .\" permission notice identical to this one.
15 .\" Since the Linux kernel and libraries are constantly changing, this
16 .\" manual page may be incorrect or out-of-date. The author(s) assume no
17 .\" responsibility for errors or omissions, or for damages resulting from
18 .\" the use of the information contained herein. The author(s) may not
19 .\" have taken the same level of care in the production of this manual,
20 .\" which is licensed free of charge, as they might when working
23 .\" Formatted or processed versions of this manual, if unaccompanied by
24 .\" the source, must acknowledge the copyright and authors of this work.
27 .\" Modified Sat Jul 24 13:35:59 1993 by Rik Faith <faith@cs.unc.edu>
28 .\" Modified Sun Nov 28 17:19:01 1993 by Rik Faith <faith@cs.unc.edu>
29 .\" Modified Sat Jan 13 12:58:08 1996 by Michael Haardt
30 .\" <michael@cantor.informatik.rwth-aachen.de>
31 .\" Modified Sun Jul 21 18:59:33 1996 by Andries Brouwer <aeb@cwi.nl>
32 .\" 2001-12-13 added remark by Zack Weinberg
34 .\" Added details about seekable files and file offset.
35 .\" Noted that write() may write less than 'count' bytes, and
36 .\" gave some examples of why this might occur.
37 .\" Noted what happens if write() is interrupted by a signal.
39 .TH WRITE 2 2021-03-22 "Linux" "Linux Programmer's Manual"
41 write \- write to a file descriptor
44 .B #include <unistd.h>
46 .BI "ssize_t write(int " fd ", const void *" buf ", size_t " count );
52 bytes from the buffer starting at
54 to the file referred to by the file descriptor
57 The number of bytes written may be less than
60 there is insufficient space on the underlying physical medium, or the
62 resource limit is encountered (see
64 or the call was interrupted by a signal
65 handler after having written less than
71 For a seekable file (i.e., one to which
73 may be applied, for example, a regular file)
74 writing takes place at the file offset,
75 and the file offset is incremented by
76 the number of bytes actually written.
81 the file offset is first set to the end of the file before writing.
82 The adjustment of the file offset and the write operation
83 are performed as an atomic step.
87 that can be proved to occur after a
89 has returned will return the new data.
90 Note that not all filesystems are POSIX conforming.
92 According to POSIX.1, if
96 the result is implementation-defined;
97 see NOTES for the upper limit on Linux.
99 On success, the number of bytes written is returned.
100 On error, \-1 is returned, and \fIerrno\fP is set
101 to indicate the error.
103 Note that a successful
105 may transfer fewer than
108 Such partial writes can occur for various reasons;
109 for example, because there was insufficient space on the disk device
110 to write all of the requested bytes, or because a blocked
112 to a socket, pipe, or similar was interrupted by a signal handler
113 after it had transferred some, but before it had transferred all
114 of the requested bytes.
115 In the event of a partial write, the caller can make another
117 call to transfer the remaining bytes.
118 The subsequent call will either transfer further bytes or
119 may result in an error (e.g., if the disk is now full).
121 If \fIcount\fP is zero and
123 refers to a regular file, then
125 may return a failure status if one of the errors below is detected.
126 If no errors are detected, or error detection is not performed,
127 0 is returned without causing any other effect.
129 \fIcount\fP is zero and
131 refers to a file other than a regular file,
132 the results are not specified.
138 refers to a file other than a socket and has been marked nonblocking
140 and the write would block.
143 for further details on the
147 .BR EAGAIN " or " EWOULDBLOCK
148 .\" Actually EAGAIN on Linux
151 refers to a socket and has been marked nonblocking
153 and the write would block.
154 POSIX.1-2001 allows either error to be returned for this case,
155 and does not require these constants to have the same value,
156 so a portable application should check for both possibilities.
160 is not a valid file descriptor or is not open for writing.
164 refers to a datagram socket for which a peer address has not been set using
168 The user's quota of disk blocks on the filesystem containing the file
175 is outside your accessible address space.
178 An attempt was made to write a file that exceeds the implementation-defined
179 maximum file size or the process's file size limit,
180 or to write at a position past the maximum allowed offset.
183 The call was interrupted by a signal before any data was written; see
188 is attached to an object which is unsuitable for writing;
189 or the file was opened with the
191 flag, and either the address specified in
193 the value specified in
195 or the file offset is not suitably aligned.
198 A low-level I/O error occurred while modifying the inode.
199 This error may relate to the write-back of data written by an earlier
201 which may have been issued to a different file descriptor on
203 Since Linux 4.13, errors from write-back come
204 with a promise that they
206 be reported by subsequent.
210 be reported by a subsequent
212 (whether or not they were also reported by
214 .\" commit 088737f44bbf6378745f5b57b035e57ee3dc4750
215 An alternate cause of
217 on networked filesystems is when an advisory lock had been taken out
218 on the file descriptor and this lock has been lost.
226 The device containing the file referred to by
228 has no room for the data.
231 The operation was prevented by a file seal; see
236 is connected to a pipe or socket whose reading end is closed.
237 When this happens the writing process will also receive a
240 (Thus, the write return value is seen only if the program
241 catches, blocks or ignores this signal.)
243 Other errors may occur, depending on the object connected to
246 SVr4, 4.3BSD, POSIX.1-2001.
247 .\" SVr4 documents additional error
248 .\" conditions EDEADLK, ENOLCK, ENOLNK, ENOSR, ENXIO, or ERANGE.
250 Under SVr4 a write may be interrupted and return
253 not just before any data is written.
260 unsigned and signed integer data types specified by POSIX.1.
262 A successful return from
264 does not make any guarantee that data has been committed to disk.
265 On some filesystems, including NFS, it does not even guarantee
266 that space has successfully been reserved for the data.
268 some errors might be delayed until a future
273 The only way to be sure is to call
275 after you are done writing all your data.
279 is interrupted by a signal handler before any bytes are written,
280 then the call fails with the error
282 if it is interrupted after at least one byte has been written,
283 the call succeeds, and returns the number of bytes written.
287 (and similar system calls) will transfer at most
288 0x7ffff000 (2,147,479,552) bytes,
289 returning the number of bytes actually transferred.
290 .\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
291 (This is true on both 32-bit and 64-bit systems.)
293 An error return value while performing
295 using direct I/O does not mean the
296 entire write has failed. Partial data may be written
297 and the data at the file offset on which the
299 was attempted should be considered inconsistent.
301 According to POSIX.1-2008/SUSv4 Section XSI 2.9.7
302 ("Thread Interactions with Regular File Operations"):
305 All of the following functions shall be atomic with respect to
306 each other in the effects specified in POSIX.1-2008 when they
307 operate on regular files or symbolic links: ...
310 Among the APIs subsequently listed are
314 And among the effects that should be atomic across threads (and processes)
315 are updates of the file offset.
316 However, on Linux before version 3.14,
317 this was not the case: if two processes that share
318 an open file description (see
324 at the same time, then the I/O operations were not atomic
325 with respect to updating the file offset,
326 with the result that the blocks of data output by the two processes
327 might (incorrectly) overlap.
328 This problem was fixed in Linux 3.14.
329 .\" http://thread.gmane.org/gmane.linux.kernel/1649458
330 .\" From: Michael Kerrisk (man-pages <mtk.manpages <at> gmail.com>
331 .\" Subject: Update of file offset on write() etc. is non-atomic with I/O
332 .\" Date: 2014-02-17 15:41:37 GMT
333 .\" Newsgroups: gmane.linux.kernel, gmane.linux.file-systems
334 .\" commit 9c225f2655e36a470c4f58dbbc99244c5fc7f2d4
335 .\" Author: Linus Torvalds <torvalds@linux-foundation.org>
336 .\" Date: Mon Mar 3 09:36:58 2014 -0800
338 .\" vfs: atomic f_pos accesses as per POSIX