1FSYNC(3P)                  POSIX Programmer's Manual                 FSYNC(3P)
2
3
4

PROLOG

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

NAME

12       fsync — synchronize changes to a file
13

SYNOPSIS

15       #include <unistd.h>
16
17       int fsync(int fildes);
18

DESCRIPTION

20       The fsync() function shall request that all  data  for  the  open  file
21       descriptor  named  by fildes is to be transferred to the storage device
22       associated with the file described by fildes.  The nature of the trans‐
23       fer  is  implementation-defined.  The fsync() function shall not return
24       until the system has  completed  that  action  or  until  an  error  is
25       detected.
26
27       If  _POSIX_SYNCHRONIZED_IO is defined, the fsync() function shall force
28       all currently queued I/O operations associated with the file  indicated
29       by file descriptor fildes to the synchronized I/O completion state. All
30       I/O operations shall be completed as defined for synchronized I/O  file
31       integrity completion.
32

RETURN VALUE

34       Upon successful completion, fsync() shall return 0. Otherwise, -1 shall
35       be returned and errno set to indicate the error. If the  fsync()  func‐
36       tion  fails, outstanding I/O operations are not guaranteed to have been
37       completed.
38

ERRORS

40       The fsync() function shall fail if:
41
42       EBADF  The fildes argument is not a valid descriptor.
43
44       EINTR  The fsync() function was interrupted by a signal.
45
46       EINVAL The fildes argument does not refer to a file on which this oper‐
47              ation is possible.
48
49       EIO    An  I/O error occurred while reading from or writing to the file
50              system.
51
52       In the event that any of the queued I/O operations fail, fsync()  shall
53       return the error conditions defined for read() and write().
54
55       The following sections are informative.
56

EXAMPLES

58       None.
59

APPLICATION USAGE

61       The fsync() function should be used by programs which require modifica‐
62       tions to a file to be completed before continuing; for example, a  pro‐
63       gram  which  contains  a  simple  transaction  facility might use it to
64       ensure that all modifications to a file or files caused by  a  transac‐
65       tion are recorded.
66

RATIONALE

68       The fsync() function is intended to force a physical write of data from
69       the buffer cache, and to assure that after  a  system  crash  or  other
70       failure that all data up to the time of the fsync() call is recorded on
71       the disk. Since the concepts of  ``buffer  cache'',  ``system  crash'',
72       ``physical  write'', and ``non-volatile storage'' are not defined here,
73       the wording has to be more abstract.
74
75       If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on
76       the conformance document to tell the user what can be expected from the
77       system. It is explicitly intended that a null implementation is permit‐
78       ted.  This  could  be  valid in the case where the system cannot assure
79       non-volatile storage under any circumstances  or  when  the  system  is
80       highly  fault-tolerant  and  the  functionality is not required. In the
81       middle ground between these extremes, fsync() might or might not  actu‐
82       ally  cause  data  to be written where it is safe from a power failure.
83       The conformance document should identify at least that  one  configura‐
84       tion  exists  (and  how to obtain that configuration) where this can be
85       assured for at least some files that the user can  select  to  use  for
86       critical  data. It is not intended that an exhaustive list is required,
87       but rather sufficient information is provided so that if critical  data
88       needs  to be saved, the user can determine how the system is to be con‐
89       figured to allow the data to be written to non-volatile storage.
90
91       It is reasonable to assert that the key aspects of fsync()  are  unrea‐
92       sonable  to  test  in a test suite. That does not make the function any
93       less valuable, just more difficult to test. A formal  conformance  test
94       should  probably  force a system crash (power shutdown) during the test
95       for this condition, but it needs to be done in such a  way  that  auto‐
96       mated  testing  does  not  require this to be done except when a formal
97       record of the results is being made. It would also not be  unreasonable
98       to omit testing for fsync(), allowing it to be treated as a quality-of-
99       implementation issue.
100

FUTURE DIRECTIONS

102       None.
103

SEE ALSO

105       sync()
106
107       The Base Definitions volume of POSIX.1‐2017, <unistd.h>
108
110       Portions of this text are reprinted and reproduced in  electronic  form
111       from  IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
112       table Operating System Interface (POSIX), The Open Group Base  Specifi‐
113       cations  Issue  7, 2018 Edition, Copyright (C) 2018 by the Institute of
114       Electrical and Electronics Engineers, Inc and The Open Group.   In  the
115       event of any discrepancy between this version and the original IEEE and
116       The Open Group Standard, the original IEEE and The Open Group  Standard
117       is  the  referee document. The original Standard can be obtained online
118       at http://www.opengroup.org/unix/online.html .
119
120       Any typographical or formatting errors that appear  in  this  page  are
121       most likely to have been introduced during the conversion of the source
122       files to man page format. To report such errors,  see  https://www.ker
123       nel.org/doc/man-pages/reporting_bugs.html .
124
125
126
127IEEE/The Open Group                  2017                            FSYNC(3P)
Impressum