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

NAME

6       fsync - synchronize changes to a file
7

SYNOPSIS

9       #include <unistd.h>
10
11       int fsync(int fildes);
12
13

DESCRIPTION

15       The  fsync()  function  shall  request  that all data for the open file
16       descriptor named by fildes is to be transferred to the  storage  device
17       associated  with  the  file  described  by fildes in an implementation-
18       defined manner. The fsync() function shall not return until the  system
19       has completed that action or until an error is detected.
20
21       If  _POSIX_SYNCHRONIZED_IO is defined, the fsync() function shall force
22       all currently queued I/O operations associated with the file  indicated
23       by file descriptor fildes to the synchronized I/O completion state. All
24       I/O operations shall be completed as defined for synchronized I/O  file
25       integrity completion.
26

RETURN VALUE

28       Upon successful completion, fsync() shall return 0. Otherwise, -1 shall
29       be returned and errno set to indicate the error. If the  fsync()  func‐
30       tion  fails, outstanding I/O operations are not guaranteed to have been
31       completed.
32

ERRORS

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

EXAMPLES

53       None.
54

APPLICATION USAGE

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

RATIONALE

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

FUTURE DIRECTIONS

97       None.
98

SEE ALSO

100       sync()  ,  the  Base  Definitions   volume   of   IEEE Std 1003.1-2001,
101       <unistd.h>
102
104       Portions  of  this text are reprinted and reproduced in electronic form
105       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
106       --  Portable  Operating  System  Interface (POSIX), The Open Group Base
107       Specifications Issue 6, Copyright (C) 2001-2003  by  the  Institute  of
108       Electrical  and  Electronics  Engineers, Inc and The Open Group. In the
109       event of any discrepancy between this version and the original IEEE and
110       The  Open Group Standard, the original IEEE and The Open Group Standard
111       is the referee document. The original Standard can be  obtained  online
112       at http://www.opengroup.org/unix/online.html .
113
114
115
116IEEE/The Open Group                  2003                             FSYNC(P)
Impressum