logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

fsync.3p (5415B)


  1. '\" et
  2. .TH FSYNC "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
  3. .\"
  4. .SH PROLOG
  5. This manual page is part of the POSIX Programmer's Manual.
  6. The Linux implementation of this interface may differ (consult
  7. the corresponding Linux manual page for details of Linux behavior),
  8. or the interface may not be implemented on Linux.
  9. .\"
  10. .SH NAME
  11. fsync
  12. \(em synchronize changes to a file
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <unistd.h>
  17. .P
  18. int fsync(int \fIfildes\fP);
  19. .fi
  20. .SH DESCRIPTION
  21. The
  22. \fIfsync\fR()
  23. function shall request that all data for the open file descriptor
  24. named by
  25. .IR fildes
  26. is to be transferred to the storage device associated with the file
  27. described by
  28. .IR fildes .
  29. The nature of the transfer is implementation-defined. The
  30. \fIfsync\fR()
  31. function shall not return until the system has completed that action
  32. or until an error is detected.
  33. .P
  34. If _POSIX_SYNCHRONIZED_IO is defined, the
  35. \fIfsync\fR()
  36. function shall force all currently queued I/O operations associated
  37. with the file indicated by file descriptor
  38. .IR fildes
  39. to the synchronized I/O completion state. All I/O operations shall be
  40. completed as defined for synchronized I/O file integrity completion.
  41. .SH "RETURN VALUE"
  42. Upon successful completion,
  43. \fIfsync\fR()
  44. shall return 0. Otherwise, \-1 shall be returned and
  45. .IR errno
  46. set to indicate the error. If the
  47. \fIfsync\fR()
  48. function fails, outstanding I/O operations are not guaranteed to have
  49. been completed.
  50. .SH ERRORS
  51. The
  52. \fIfsync\fR()
  53. function shall fail if:
  54. .TP
  55. .BR EBADF
  56. The
  57. .IR fildes
  58. argument is not a valid descriptor.
  59. .TP
  60. .BR EINTR
  61. The
  62. \fIfsync\fR()
  63. function was interrupted by a signal.
  64. .TP
  65. .BR EINVAL
  66. The
  67. .IR fildes
  68. argument does not refer to a file on which this operation is possible.
  69. .TP
  70. .BR EIO
  71. An I/O error occurred while reading from or writing to the file system.
  72. .P
  73. In the event that any of the queued I/O operations fail,
  74. \fIfsync\fR()
  75. shall return the error conditions defined for
  76. \fIread\fR()
  77. and
  78. \fIwrite\fR().
  79. .LP
  80. .IR "The following sections are informative."
  81. .SH EXAMPLES
  82. None.
  83. .SH "APPLICATION USAGE"
  84. The
  85. \fIfsync\fR()
  86. function should be used by programs which require modifications to a
  87. file to be completed before continuing; for example, a program which
  88. contains a simple transaction facility might use it to ensure that all
  89. modifications to a file or files caused by a transaction are recorded.
  90. .SH RATIONALE
  91. The
  92. \fIfsync\fR()
  93. function is intended to force a physical write of data from the buffer
  94. cache, and to assure that after a system crash or other failure that
  95. all data up to the time of the
  96. \fIfsync\fR()
  97. call is recorded on the disk. Since the concepts of ``buffer cache'',
  98. ``system crash'', ``physical write'', and ``non-volatile storage''
  99. are not defined here, the wording has to be more abstract.
  100. .P
  101. If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on
  102. the conformance document to tell the user what can be expected from the
  103. system. It is explicitly intended that a null implementation is
  104. permitted. This could be valid in the case where the system cannot
  105. assure non-volatile storage under any circumstances or when the system
  106. is highly fault-tolerant and the functionality is not required. In the
  107. middle ground between these extremes,
  108. \fIfsync\fR()
  109. might or might not actually cause data to be written where it is safe
  110. from a power failure. The conformance document should identify at least
  111. that one configuration exists (and how to obtain that configuration)
  112. where this can be assured for at least some files that the user can
  113. select to use for critical data. It is not intended that an exhaustive
  114. list is required, but rather sufficient information is provided so that
  115. if critical data needs to be saved, the user can determine how the
  116. system is to be configured to allow the data to be written to
  117. non-volatile storage.
  118. .P
  119. It is reasonable to assert that the key aspects of
  120. \fIfsync\fR()
  121. are unreasonable to test in a test suite. That does not make the
  122. function any less valuable, just more difficult to test. A formal
  123. conformance test should probably force a system crash (power shutdown)
  124. during the test for this condition, but it needs to be done in such a
  125. way that automated testing does not require this to be done except when
  126. a formal record of the results is being made. It would also not be
  127. unreasonable to omit testing for
  128. \fIfsync\fR(),
  129. allowing it to be treated as a quality-of-implementation issue.
  130. .SH "FUTURE DIRECTIONS"
  131. None.
  132. .SH "SEE ALSO"
  133. .IR "\fIsync\fR\^(\|)"
  134. .P
  135. The Base Definitions volume of POSIX.1\(hy2017,
  136. .IR "\fB<unistd.h>\fP"
  137. .\"
  138. .SH COPYRIGHT
  139. Portions of this text are reprinted and reproduced in electronic form
  140. from IEEE Std 1003.1-2017, Standard for Information Technology
  141. -- Portable Operating System Interface (POSIX), The Open Group Base
  142. Specifications Issue 7, 2018 Edition,
  143. Copyright (C) 2018 by the Institute of
  144. Electrical and Electronics Engineers, Inc and The Open Group.
  145. In the event of any discrepancy between this version and the original IEEE and
  146. The Open Group Standard, the original IEEE and The Open Group Standard
  147. is the referee document. The original Standard can be obtained online at
  148. http://www.opengroup.org/unix/online.html .
  149. .PP
  150. Any typographical or formatting errors that appear
  151. in this page are most likely
  152. to have been introduced during the conversion of the source files to
  153. man page format. To report such errors, see
  154. https://www.kernel.org/doc/man-pages/reporting_bugs.html .