PROLOG

       This  manual  page  is part of the POSIX Programmer's Manual.  The Linux implementation of this interface
       may differ (consult the corresponding Linux manual page for details of Linux behavior), or the  interface
       may not be implemented on Linux.

NAME

       fsync — synchronize changes to a file

SYNOPSIS

       #include <unistd.h>

       int fsync(int fildes);

DESCRIPTION

       The  fsync()  function  shall request that all data for the open file descriptor named by fildes is to be
       transferred to the storage device associated with the file  described  by  fildes.   The  nature  of  the
       transfer  is implementation-defined. The fsync() function shall not return until the system has completed
       that action or until an error is detected.

       If _POSIX_SYNCHRONIZED_IO is  defined,  the  fsync()  function  shall  force  all  currently  queued  I/O
       operations  associated  with  the  file  indicated  by  file  descriptor  fildes  to the synchronized I/O
       completion state. All I/O operations shall be completed as defined for synchronized  I/O  file  integrity
       completion.

RETURN VALUE

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

ERRORS

       The fsync() function shall fail if:

       EBADF  The fildes argument is not a valid descriptor.

       EINTR  The fsync() function was interrupted by a signal.

       EINVAL The fildes argument does not refer to a file on which this operation is possible.

       EIO    An I/O error occurred while reading from or writing to the file system.

       In  the  event  that  any  of  the  queued I/O operations fail, fsync() shall return the error conditions
       defined for read() and write().

       The following sections are informative.

EXAMPLES

       None.

APPLICATION USAGE

       The fsync() function should be used by programs which require modifications to a  file  to  be  completed
       before  continuing;  for  example, a program which contains a simple transaction facility might use it to
       ensure that all modifications to a file or files caused by a transaction are recorded.

RATIONALE

       The fsync() function is intended to force a physical write of data from the buffer cache, and  to  assure
       that  after  a system crash or other failure that all data up to the time of the fsync() call is recorded
       on the disk. Since the concepts of ``buffer cache'', ``system crash'',  ``physical  write'',  and  ``non-
       volatile storage'' are not defined here, the wording has to be more abstract.

       If  _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on the conformance document to tell
       the user what can be expected from the system. It is explicitly intended that a  null  implementation  is
       permitted.  This could be valid in the case where the system cannot assure non-volatile storage under any
       circumstances or when the system is highly fault-tolerant and the functionality is not required.  In  the
       middle  ground between these extremes, fsync() might or might not actually cause data to be written where
       it is safe from a power failure. The conformance document should identify at least that one configuration
       exists (and how to obtain that configuration) where this can be assured for at least some files that  the
       user  can  select  to  use for critical data. It is not intended that an exhaustive list is required, but
       rather sufficient information is provided so that if critical data  needs  to  be  saved,  the  user  can
       determine how the system is to be configured to allow the data to be written to non-volatile storage.

       It is reasonable to assert that the key aspects of fsync() are unreasonable to test in a test suite. That
       does  not  make  the  function  any less valuable, just more difficult to test. A formal conformance test
       should probably force a system crash (power shutdown) during the test for this condition, but it needs to
       be done in such a way that automated testing does not require this to be done except when a formal record
       of the results is being made. It would also not be unreasonable to omit testing for fsync(), allowing  it
       to be treated as a quality-of-implementation issue.

FUTURE DIRECTIONS

       None.

SEE ALSO

       sync()

       The Base Definitions volume of POSIX.1‐2017, <unistd.h>

COPYRIGHT

       Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard
       for  Information  Technology  --  Portable  Operating  System  Interface  (POSIX),  The  Open  Group Base
       Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical  and  Electronics
       Engineers, Inc and The Open Group.  In the event of any discrepancy between this version and the original
       IEEE  and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document.
       The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

       Any typographical or formatting errors that appear in this page are most likely to have  been  introduced
       during   the   conversion  of  the  source  files  to  man  page  format.  To  report  such  errors,  see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .

IEEE/The Open Group                                   2017                                         FSYNC(3POSIX)