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
19

DESCRIPTION

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  in  an  implementation-
24       defined  manner. The fsync() function shall not return until the system
25       has completed that action or until an error is 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
53       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
56       The following sections are informative.
57

EXAMPLES

59       None.
60

APPLICATION USAGE

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

RATIONALE

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", "physi‐
73       cal write", and "non-volatile storage" are not defined here, the  word‐
74       ing has to be more abstract.
75
76       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
92       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

FUTURE DIRECTIONS

103       None.
104

SEE ALSO

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