1FSYNC(3P) POSIX Programmer's Manual FSYNC(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
13 fsync — synchronize changes to a file
14
16 #include <unistd.h>
17 int fsync(int fildes);
19
21 The fsync() function shall request that all data for the open file
22 descriptor named by fildes is to be transferred to the storage device
23 associated with the file described by fildes. The nature of the trans‐
24 fer is implementation-defined. The fsync() function shall not return
25 until the system has completed that action or until an error is
26 detected.
27 If _POSIX_SYNCHRONIZED_IO is defined, the fsync() function shall force
29 all currently queued I/O operations associated with the file indicated
30 by file descriptor fildes to the synchronized I/O completion state. All
31 I/O operations shall be completed as defined for synchronized I/O file
32 integrity completion.
33
35 Upon successful completion, fsync() shall return 0. Otherwise, −1 shall
36 be returned and errno set to indicate the error. If the fsync() func‐
37 tion fails, outstanding I/O operations are not guaranteed to have been
38 completed.
39
41 The fsync() function shall fail if:
42 EBADF The fildes argument is not a valid descriptor.
44 EINTR The fsync() function was interrupted by a signal.
46 EINVAL The fildes argument does not refer to a file on which this oper‐
48 ation is possible.
49 EIO An I/O error occurred while reading from or writing to the file
51 system.
52 In the event that any of the queued I/O operations fail, fsync() shall
54 return the error conditions defined for read() and write().
55 The following sections are informative.
57
59 None.
60
62 The fsync() function should be used by programs which require modifica‐
63 tions to a file to be completed before continuing; for example, a pro‐
64 gram which contains a simple transaction facility might use it to
65 ensure that all modifications to a file or files caused by a transac‐
66 tion are recorded.
67
69 The fsync() function is intended to force a physical write of data from
70 the buffer cache, and to assure that after a system crash or other
71 failure that all data up to the time of the fsync() call is recorded on
72 the disk. Since the concepts of ``buffer cache'', ``system crash'',
73 ``physical write'', and ``non-volatile storage'' are not defined here,
74 the wording has to be more abstract.
75 If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on
77 the conformance document to tell the user what can be expected from the
78 system. It is explicitly intended that a null implementation is permit‐
79 ted. This could be valid in the case where the system cannot assure
80 non-volatile storage under any circumstances or when the system is
81 highly fault-tolerant and the functionality is not required. In the
82 middle ground between these extremes, fsync() might or might not actu‐
83 ally cause data to be written where it is safe from a power failure.
84 The conformance document should identify at least that one configura‐
85 tion exists (and how to obtain that configuration) where this can be
86 assured for at least some files that the user can select to use for
87 critical data. It is not intended that an exhaustive list is required,
88 but rather sufficient information is provided so that if critical data
89 needs to be saved, the user can determine how the system is to be con‐
90 figured to allow the data to be written to non-volatile storage.
91 It is reasonable to assert that the key aspects of fsync() are unrea‐
93 sonable to test in a test suite. That does not make the function any
94 less valuable, just more difficult to test. A formal conformance test
95 should probably force a system crash (power shutdown) during the test
96 for this condition, but it needs to be done in such a way that auto‐
97 mated testing does not require this to be done except when a formal
98 record of the results is being made. It would also not be unreasonable
99 to omit testing for fsync(), allowing it to be treated as a quality-of-
100 implementation issue.
101
103 None.
104
106 sync()
107 The Base Definitions volume of POSIX.1‐2008, <unistd.h>
109
111 Portions of this text are reprinted and reproduced in electronic form
112 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
113 -- Portable Operating System Interface (POSIX), The Open Group Base
114 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
115 cal and Electronics Engineers, Inc and The Open Group. (This is
116 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
117 event of any discrepancy between this version and the original IEEE and
118 The Open Group Standard, the original IEEE and The Open Group Standard
119 is the referee document. The original Standard can be obtained online
120 at http://www.unix.org/online.html .
121 Any typographical or formatting errors that appear in this page are
123 most likely to have been introduced during the conversion of the source
124 files to man page format. To report such errors, see https://www.ker‐
125 nel.org/doc/man-pages/reporting_bugs.html .
126IEEE/The Open Group 2013 FSYNC(3P)