Case Study

I now introduce a case study of a real-world system call manual, in particular the manual for the fsync function from OpenBSD. The original file may be viewed on-line at src/lib/libc/sys/fsync.2, file version 1.9.

.\" $OpenBSD: fsync.2,v 1.9 2011/04/29 07:12:44 jmc Exp $
.\" $NetBSD: fsync.2,v 1.4 1995/02/27 12:32:38 cgd Exp $
.\"
.\" Copyright (c) 1983, 1993
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)fsync.2 8.1 (Berkeley) 6/4/93

The cvs identifiers (both from the current system, OpenBSD, and the import source system, NetBSD), copyright, license, and sccs identifier (from the original system) are presented in the usual way: the the $OpenBSD$ and $NetBSD$ lines are automatically updated by the revision control system, cvs, whenever an update to the file is committed. The line following is the copyright message, and following that is the text form of the BSD license.

.Dd $Mdocdate: April 29 2011 $
.Dt FSYNC 2
.Os

The manual's last-modified date is maintained with the automatically-updated $Mdocdate$ sequence. Its title is set to the single function's capitalised form, category 2 for system calls under the current operating system.

.Sh NAME
.Nm fsync
.Nd "synchronize a file's in-core state with that on disk"

.Sh SYNOPSIS
.Fd #include <unistd.h>
.Ft int
.Fn fsync "int fd"

Again, in historical manuals, Fd is sometimes used instead of the modern In macro. Note also the inclusion of the function argument's name, fd, where regular C prototypes would usually only include the type.

.Sh DESCRIPTION
.Fn fsync
causes all modified data and attributes of
.Fa fd
to be moved to a permanent storage device.
This normally results in all in-core modified copies
of buffers for the associated file to be written to a disk.
.Pp
.Fn fsync
should be used by programs that require a file to be in a known state,
for example, in building a simple transaction facility.

Since fsync is a simple function, its description is fairly straightforward. The single function argument fd is fully described as well.

.Sh RETURN VALUES
A 0 value is returned on success.
A \-1 value indicates an error.

This is not correct, as it omits information on the errno global error being set. The Rv macro should be used instead.

.Sh ERRORS
The
.Fn fsync
fails if:
.Bl -tag -width Er
.It Bq Er EBADF
.Fa fd
is not a valid descriptor.
.It Bq Er EINVAL
.Fa fd
refers to a socket, not to a file.
.It Bq Er EIO
An I/O error occurred while reading from or writing to the file system.
.El

Most (if not all) system calls set the errno global error upon failure. This, erroneously, was not mentioned in the RETURN VALUES section, but is documented here.

.Sh SEE ALSO
.Xr sync 2 ,
.Xr sync 8
.Sh HISTORY
The
.Fn fsync
function call appeared in
.Bx 4.2 .

Note that the cross-references in SEE ALSO are ordered first by section, then alphabetically. The Bx is referenced as the origin of the system call. The STANDARDS section is sorely missing, as fsync is a function specified by POSIX.1-2008 standard.

We again found several inconsistent uses of mdoc in this case study. Let this serve as a reminder that if you find bad or unusual mdoc in your manuals, notify the authors! A bug in a manual is just as important as a bug in the code.