This chapter describes functions for performing low-level input/output
operations on file descriptors. These functions include the primitives
for the higher-level I/O functions described in 12. Input/Output on Streams, as
well as functions for performing low-level control operations for which
there are no equivalents on streams.
Stream-level I/O is more flexible and usually more convenient;
therefore, programmers generally use the descriptor-level functions only
when necessary. These are some of the usual reasons:
For reading binary files in large chunks.
For reading an entire file into core before parsing it.
To perform operations other than data transfer, which can only be done
with a descriptor. (You can use fileno to get the descriptor
corresponding to a stream.)
To pass descriptors to a child process. (The child can create its own
stream to use a descriptor that it inherits, but cannot inherit a stream
directly.)
This section describes the primitives for opening and closing files
using file descriptors. The open and creat functions are
declared in the header file `fcntl.h', while close is
declared in `unistd.h'.
Function: int open(const char *filename, int flags[, mode_t mode])
The open function creates and returns a new file descriptor
for the file named by filename. Initially, the file position
indicator for the file is at the beginning of the file. The argument
mode is used only when a file is created, but it doesn't hurt
to supply the argument in any case.
The flags argument controls how the file is to be opened. This is
a bit mask; you create the value by the bitwise OR of the appropriate
parameters (using the `|' operator in C).
See section 13.14 File Status Flags, for the parameters available.
The normal return value from open is a non-negative integer file
descriptor. In the case of an error, a value of -1 is returned
instead. In addition to the usual file name errors (see section 11.2.3 File Name Errors), the following errno error conditions are defined
for this function:
EACCES
The file exists but is not readable/writable as requested by the flags
argument, the file does not exist and the directory is unwritable so
it cannot be created.
EEXIST
Both O_CREAT and O_EXCL are set, and the named file already
exists.
The flags argument specified write access, and the file is a directory.
EMFILE
The process has too many files open.
The maximum number of file descriptors is controlled by the
RLIMIT_NOFILE resource limit; see section 22.2 Limiting Resource Usage.
ENFILE
The entire system, or perhaps the file system which contains the
directory, cannot support any additional open files at the moment.
(This problem cannot happen on the GNU system.)
ENOENT
The named file does not exist, and O_CREAT is not specified.
ENOSPC
The directory or file system that would contain the new file cannot be
extended, because there is no disk space left.
ENXIO
O_NONBLOCK and O_WRONLY are both set in the flags
argument, the file named by filename is a FIFO (see section 15. Pipes and FIFOs), and no process has the file open for reading.
EROFS
The file resides on a read-only file system and any of O_WRONLY,
O_RDWR, and O_TRUNC are set in the flags argument,
or O_CREAT is set and the file does not already exist.
If on a 32 bit machine the sources are translated with
_FILE_OFFSET_BITS == 64 the function open returns a file
descriptor opened in the large file mode which enables the file handling
functions to use files up to 2^63 bytes in size and offset from
-2^63 to 2^63. This happens transparently for the user
since all of the lowlevel file handling functions are equally replaced.
This function is a cancellation point in multi-threaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time open is
called. If the thread gets canceled these resources stay allocated
until the program ends. To avoid this calls to open should be
protected using cancellation handlers.
The open function is the underlying primitive for the fopen
and freopen functions, that create streams.
Function: int open64(const char *filename, int flags[, mode_t mode])
This function is similar to open. It returns a file descriptor
which can be used to access the file named by filename. The only
difference is that on 32 bit systems the file is opened in the
large file mode. I.e., file length and file offsets can exceed 31 bits.
When the sources are translated with _FILE_OFFSET_BITS == 64 this
function is actually available under the name open. I.e., the
new, extended API using 64 bit file sizes and offsets transparently
replaces the old API.
Obsolete function: int creat(const char *filename, mode_t mode)
This function is obsolete. The call:
creat (filename, mode)
is equivalent to:
open (filename, O_WRONLY | O_CREAT | O_TRUNC, mode)
If on a 32 bit machine the sources are translated with
_FILE_OFFSET_BITS == 64 the function creat returns a file
descriptor opened in the large file mode which enables the file handling
functions to use files up to 2^63 in size and offset from
-2^63 to 2^63. This happens transparently for the user
since all of the lowlevel file handling functions are equally replaced.
Obsolete function: int creat64(const char *filename, mode_t mode)
This function is similar to creat. It returns a file descriptor
which can be used to access the file named by filename. The only
the difference is that on 32 bit systems the file is opened in the
large file mode. I.e., file length and file offsets can exceed 31 bits.
To use this file descriptor one must not use the normal operations but
instead the counterparts named *64, e.g., read64.
When the sources are translated with _FILE_OFFSET_BITS == 64 this
function is actually available under the name open. I.e., the
new, extended API using 64 bit file sizes and offsets transparently
replaces the old API.
Function: int close(int filedes)
The function close closes the file descriptor filedes.
Closing a file has the following consequences:
The file descriptor is deallocated.
Any record locks owned by the process on the file are unlocked.
When all file descriptors associated with a pipe or FIFO have been closed,
any unread data is discarded.
This function is a cancellation point in multi-threaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time close is
called. If the thread gets canceled these resources stay allocated
until the program ends. To avoid this, calls to close should be
protected using cancellation handlers.
The normal return value from close is 0; a value of -1
is returned in case of failure. The following errno error
conditions are defined for this function:
EBADF
The filedes argument is not a valid file descriptor.
When the file is accessed by NFS, these errors from write can sometimes
not be detected until close. See section 13.2 Input and Output Primitives, for details
on their meaning.
Please note that there is no separate close64 function.
This is not necessary since this function does not determine nor depend
on the mode of the file. The kernel which performs the close
operation knows which mode the descriptor is used for and can handle
this situation.
To close a stream, call fclose (see section 12.4 Closing Streams) instead
of trying to close its underlying file descriptor with close.
This flushes any buffered output and updates the stream object to
indicate that it is closed.
This section describes the functions for performing primitive input and
output operations on file descriptors: read, write, and
lseek. These functions are declared in the header file
`unistd.h'.
Data Type:ssize_t
This data type is used to represent the sizes of blocks that can be
read or written in a single operation. It is similar to size_t,
but must be a signed type.
The read function reads up to size bytes from the file
with descriptor filedes, storing the results in the buffer.
(This is not necessarily a character string, and no terminating null
character is added.)
The return value is the number of bytes actually read. This might be
less than size; for example, if there aren't that many bytes left
in the file or if there aren't that many bytes immediately available.
The exact behavior depends on what kind of file it is. Note that
reading less than size bytes is not an error.
A value of zero indicates end-of-file (except if the value of the
size argument is also zero). This is not considered an error.
If you keep calling read while at end-of-file, it will keep
returning zero and doing nothing else.
If read returns at least one character, there is no way you can
tell whether end-of-file was reached. But if you did reach the end, the
next read will return zero.
In case of an error, read returns -1. The following
errno error conditions are defined for this function:
EAGAIN
Normally, when no input is immediately available, read waits for
some input. But if the O_NONBLOCK flag is set for the file
(see section 13.14 File Status Flags), read returns immediately without
reading any data, and reports this error.
Compatibility Note: Most versions of BSD Unix use a different
error code for this: EWOULDBLOCK. In the GNU library,
EWOULDBLOCK is an alias for EAGAIN, so it doesn't matter
which name you use.
On some systems, reading a large amount of data from a character special
file can also fail with EAGAIN if the kernel cannot find enough
physical memory to lock down the user's pages. This is limited to
devices that transfer with direct memory access into the user's memory,
which means it does not include terminals, since they always use
separate buffers inside the kernel. This problem never happens in the
GNU system.
Any condition that could result in EAGAIN can instead result in a
successful read which returns fewer bytes than requested.
Calling read again immediately would result in EAGAIN.
EBADF
The filedes argument is not a valid file descriptor,
or is not open for reading.
EINTR
read was interrupted by a signal while it was waiting for input.
See section 24.5 Primitives Interrupted by Signals. A signal will not necessary cause
read to return EINTR; it may instead result in a
successful read which returns fewer bytes than requested.
EIO
For many devices, and for disk files, this error code indicates
a hardware error.
EIO also occurs when a background process tries to read from the
controlling terminal, and the normal action of stopping the process by
sending it a SIGTTIN signal isn't working. This might happen if
the signal is being blocked or ignored, or because the process group is
orphaned. See section 27. Job Control, for more information about job control,
and 24. Signal Handling, for information about signals.
Please note that there is no function named read64. This is not
necessary since this function does not directly modify or handle the
possibly wide file offset. Since the kernel handles this state
internally, the read function can be used for all cases.
This function is a cancellation point in multi-threaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time read is
called. If the thread gets canceled these resources stay allocated
until the program ends. To avoid this, calls to read should be
protected using cancellation handlers.
The read function is the underlying primitive for all of the
functions that read from streams, such as fgetc.
The pread function is similar to the read function. The
first three arguments are identical, and the return values and error
codes also correspond.
The difference is the fourth argument and its handling. The data block
is not read from the current position of the file descriptor
filedes. Instead the data is read from the file starting at
position offset. The position of the file descriptor itself is
not affected by the operation. The value is the same as before the call.
When the source file is compiled with _FILE_OFFSET_BITS == 64 the
pread function is in fact pread64 and the type
off_t has 64 bits, which makes it possible to handle files up to
2^63 bytes in length.
The return value of pread describes the number of bytes read.
In the error case it returns -1 like read does and the
error codes are also the same, with these additions:
EINVAL
The value given for offset is negative and therefore illegal.
ESPIPE
The file descriptor filedes is associate with a pipe or a FIFO and
this device does not allow positioning of the file pointer.
The function is an extension defined in the Unix Single Specification
version 2.
This function is similar to the pread function. The difference
is that the offset parameter is of type off64_t instead of
off_t which makes it possible on 32 bit machines to address
files larger than 2^31 bytes and up to 2^63 bytes. The
file descriptor filedes must be opened using open64 since
otherwise the large offsets possible with off64_t will lead to
errors with a descriptor in small file mode.
When the source file is compiled with _FILE_OFFSET_BITS == 64 on a
32 bit machine this function is actually available under the name
pread and so transparently replaces the 32 bit interface.
The write function writes up to size bytes from
buffer to the file with descriptor filedes. The data in
buffer is not necessarily a character string and a null character is
output like any other character.
The return value is the number of bytes actually written. This may be
size, but can always be smaller. Your program should always call
write in a loop, iterating until all the data is written.
Once write returns, the data is enqueued to be written and can be
read back right away, but it is not necessarily written out to permanent
storage immediately. You can use fsync when you need to be sure
your data has been permanently stored before continuing. (It is more
efficient for the system to batch up consecutive writes and do them all
at once when convenient. Normally they will always be written to disk
within a minute or less.) Modern systems provide another function
fdatasync which guarantees integrity only for the file data and
is therefore faster.
You can use the O_FSYNC open mode to make write always
store the data to disk before returning; see section 13.14.3 I/O Operating Modes.
In the case of an error, write returns -1. The following
errno error conditions are defined for this function:
EAGAIN
Normally, write blocks until the write operation is complete.
But if the O_NONBLOCK flag is set for the file (see section 13.11 Control Operations on Files), it returns immediately without writing any data and
reports this error. An example of a situation that might cause the
process to block on output is writing to a terminal device that supports
flow control, where output has been suspended by receipt of a STOP
character.
Compatibility Note: Most versions of BSD Unix use a different
error code for this: EWOULDBLOCK. In the GNU library,
EWOULDBLOCK is an alias for EAGAIN, so it doesn't matter
which name you use.
On some systems, writing a large amount of data from a character special
file can also fail with EAGAIN if the kernel cannot find enough
physical memory to lock down the user's pages. This is limited to
devices that transfer with direct memory access into the user's memory,
which means it does not include terminals, since they always use
separate buffers inside the kernel. This problem does not arise in the
GNU system.
EBADF
The filedes argument is not a valid file descriptor,
or is not open for writing.
EFBIG
The size of the file would become larger than the implementation can support.
EINTR
The write operation was interrupted by a signal while it was
blocked waiting for completion. A signal will not necessarily cause
write to return EINTR; it may instead result in a
successful write which writes fewer bytes than requested.
See section 24.5 Primitives Interrupted by Signals.
EIO
For many devices, and for disk files, this error code indicates
a hardware error.
ENOSPC
The device containing the file is full.
EPIPE
This error is returned when you try to write to a pipe or FIFO that
isn't open for reading by any process. When this happens, a SIGPIPE
signal is also sent to the process; see 24. Signal Handling.
Unless you have arranged to prevent EINTR failures, you should
check errno after each failing call to write, and if the
error was EINTR, you should simply repeat the call.
See section 24.5 Primitives Interrupted by Signals. The easy way to do this is with the
macro TEMP_FAILURE_RETRY, as follows:
Please note that there is no function named write64. This is not
necessary since this function does not directly modify or handle the
possibly wide file offset. Since the kernel handles this state
internally the write function can be used for all cases.
This function is a cancellation point in multi-threaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time write is
called. If the thread gets canceled these resources stay allocated
until the program ends. To avoid this, calls to write should be
protected using cancellation handlers.
The write function is the underlying primitive for all of the
functions that write to streams, such as fputc.
The pwrite function is similar to the write function. The
first three arguments are identical, and the return values and error codes
also correspond.
The difference is the fourth argument and its handling. The data block
is not written to the current position of the file descriptor
filedes. Instead the data is written to the file starting at
position offset. The position of the file descriptor itself is
not affected by the operation. The value is the same as before the call.
When the source file is compiled with _FILE_OFFSET_BITS == 64 the
pwrite function is in fact pwrite64 and the type
off_t has 64 bits, which makes it possible to handle files up to
2^63 bytes in length.
The return value of pwrite describes the number of written bytes.
In the error case it returns -1 like write does and the
error codes are also the same, with these additions:
EINVAL
The value given for offset is negative and therefore illegal.
ESPIPE
The file descriptor filedes is associated with a pipe or a FIFO and
this device does not allow positioning of the file pointer.
The function is an extension defined in the Unix Single Specification
version 2.
This function is similar to the pwrite function. The difference
is that the offset parameter is of type off64_t instead of
off_t which makes it possible on 32 bit machines to address
files larger than 2^31 bytes and up to 2^63 bytes. The
file descriptor filedes must be opened using open64 since
otherwise the large offsets possible with off64_t will lead to
errors with a descriptor in small file mode.
When the source file is compiled using _FILE_OFFSET_BITS == 64 on a
32 bit machine this function is actually available under the name
pwrite and so transparently replaces the 32 bit interface.
Just as you can set the file position of a stream with fseek, you
can set the file position of a descriptor with lseek. This
specifies the position in the file for the next read or
write operation. See section 12.18 File Positioning, for more information
on the file position and what it means.
To read the current file position value from a descriptor, use
lseek (desc, 0, SEEK_CUR).
Function: off_t lseek(int filedes, off_t offset, int whence)
The lseek function is used to change the file position of the
file with descriptor filedes.
The whence argument specifies how the offset should be
interpreted, in the same way as for the fseek function, and it must
be one of the symbolic constants SEEK_SET, SEEK_CUR, or
SEEK_END.
SEEK_SET
Specifies that whence is a count of characters from the beginning
of the file.
SEEK_CUR
Specifies that whence is a count of characters from the current
file position. This count may be positive or negative.
SEEK_END
Specifies that whence is a count of characters from the end of
the file. A negative count specifies a position within the current
extent of the file; a positive count specifies a position past the
current end. If you set the position past the current end, and
actually write data, you will extend the file with zeros up to that
position.
The return value from lseek is normally the resulting file
position, measured in bytes from the beginning of the file.
You can use this feature together with SEEK_CUR to read the
current file position.
If you want to append to the file, setting the file position to the
current end of file with SEEK_END is not sufficient. Another
process may write more data after you seek but before you write,
extending the file so the position you write onto clobbers their data.
Instead, use the O_APPEND operating mode; see section 13.14.3 I/O Operating Modes.
You can set the file position past the current end of the file. This
does not by itself make the file longer; lseek never changes the
file. But subsequent output at that position will extend the file.
Characters between the previous end of file and the new position are
filled with zeros. Extending the file in this way can create a
"hole": the blocks of zeros are not actually allocated on disk, so the
file takes up less space than it appears to; it is then called a
"sparse file".
If the file position cannot be changed, or the operation is in some way
invalid, lseek returns a value of -1. The following
errno error conditions are defined for this function:
EBADF
The filedes is not a valid file descriptor.
EINVAL
The whence argument value is not valid, or the resulting
file offset is not valid. A file offset is invalid.
ESPIPE
The filedes corresponds to an object that cannot be positioned,
such as a pipe, FIFO or terminal device. (POSIX.1 specifies this error
only for pipes and FIFOs, but in the GNU system, you always get
ESPIPE if the object is not seekable.)
When the source file is compiled with _FILE_OFFSET_BITS == 64 the
lseek function is in fact lseek64 and the type
off_t has 64 bits which makes it possible to handle files up to
2^63 bytes in length.
This function is a cancellation point in multi-threaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time lseek is
called. If the thread gets canceled these resources stay allocated
until the program ends. To avoid this calls to lseek should be
protected using cancellation handlers.
The lseek function is the underlying primitive for the
fseek, fseeko, ftell, ftello and
rewind functions, which operate on streams instead of file
descriptors.
Function: off64_t lseek64(int filedes, off64_t offset, int whence)
This function is similar to the lseek function. The difference
is that the offset parameter is of type off64_t instead of
off_t which makes it possible on 32 bit machines to address
files larger than 2^31 bytes and up to 2^63 bytes. The
file descriptor filedes must be opened using open64 since
otherwise the large offsets possible with off64_t will lead to
errors with a descriptor in small file mode.
When the source file is compiled with _FILE_OFFSET_BITS == 64 on a
32 bits machine this function is actually available under the name
lseek and so transparently replaces the 32 bit interface.
You can have multiple descriptors for the same file if you open the file
more than once, or if you duplicate a descriptor with dup.
Descriptors that come from separate calls to open have independent
file positions; using lseek on one descriptor has no effect on the
other. For example,
{
int d1, d2;
char buf[4];
d1 = open ("foo", O_RDONLY);
d2 = open ("foo", O_RDONLY);
lseek (d1, 1024, SEEK_SET);
read (d2, buf, 4);
}
will read the first four characters of the file `foo'. (The
error-checking code necessary for a real program has been omitted here
for brevity.)
By contrast, descriptors made by duplication share a common file
position with the original descriptor that was duplicated. Anything
which alters the file position of one of the duplicates, including
reading or writing data, affects all of them alike. Thus, for example,
will read four characters starting with the 1024'th character of
`foo', and then four more characters starting with the 1028'th
character.
Data Type:off_t
This is an arithmetic data type used to represent file sizes.
In the GNU system, this is equivalent to fpos_t or long int.
If the source is compiled with _FILE_OFFSET_BITS == 64 this type
is transparently replaced by off64_t.
Data Type:off64_t
This type is used similar to off_t. The difference is that even
on 32 bit machines, where the off_t type would have 32 bits,
off64_t has 64 bits and so is able to address files up to
2^63 bytes in length.
When compiling with _FILE_OFFSET_BITS == 64 this type is
available under the name off_t.
These aliases for the `SEEK_...' constants exist for the sake
of compatibility with older BSD systems. They are defined in two
different header files: `fcntl.h' and `sys/file.h'.
Given an open file descriptor, you can create a stream for it with the
fdopen function. You can get the underlying file descriptor for
an existing stream with the fileno function. These functions are
declared in the header file `stdio.h'.
The fdopen function returns a new stream for the file descriptor
filedes.
The opentype argument is interpreted in the same way as for the
fopen function (see section 12.3 Opening Streams), except that
the `b' option is not permitted; this is because GNU makes no
distinction between text and binary files. Also, "w" and
"w+" do not cause truncation of the file; these have an effect only
when opening a file, and in this case the file has already been opened.
You must make sure that the opentype argument matches the actual
mode of the open file descriptor.
The return value is the new stream. If the stream cannot be created
(for example, if the modes for the file indicated by the file descriptor
do not permit the access specified by the opentype argument), a
null pointer is returned instead.
In some other systems, fdopen may fail to detect that the modes
for file descriptor do not permit the access specified by
opentype. The GNU C library always checks for this.
For an example showing the use of the fdopen function,
see 15.1 Creating a Pipe.
Function: int fileno(FILE *stream)
This function returns the file descriptor associated with the stream
stream. If an error is detected (for example, if the stream
is not valid) or if stream does not do I/O to a file,
fileno returns -1.
Function: int fileno_unlocked(FILE *stream)
The fileno_unlocked function is equivalent to the fileno
function except that it does not implicitly lock the stream if the state
is FSETLOCKING_INTERNAL.
This function is a GNU extension.
There are also symbolic constants defined in `unistd.h' for the
file descriptors belonging to the standard streams stdin,
stdout, and stderr; see 12.2 Standard Streams.
STDIN_FILENO
This macro has value 0, which is the file descriptor for
standard input.
STDOUT_FILENO
This macro has value 1, which is the file descriptor for
standard output.
STDERR_FILENO
This macro has value 2, which is the file descriptor for
standard error output.
You can have multiple file descriptors and streams (let's call both
streams and descriptors "channels" for short) connected to the same
file, but you must take care to avoid confusion between channels. There
are two cases to consider: linked channels that share a single
file position value, and independent channels that have their own
file positions.
It's best to use just one channel in your program for actual data
transfer to any given file, except when all the access is for input.
For example, if you open a pipe (something you can only do at the file
descriptor level), either do all I/O with the descriptor, or construct a
stream from the descriptor with fdopen and then do all I/O with
the stream.
Channels that come from a single opening share the same file position;
we call them linked channels. Linked channels result when you
make a stream from a descriptor using fdopen, when you get a
descriptor from a stream with fileno, when you copy a descriptor
with dup or dup2, and when descriptors are inherited
during fork. For files that don't support random access, such as
terminals and pipes, all channels are effectively linked. On
random-access files, all append-type output streams are effectively
linked to each other.
If you have been using a stream for I/O, and you want to do I/O using
another channel (either a stream or a descriptor) that is linked to it,
you must first clean up the stream that you have been using.
See section 13.5.3 Cleaning Streams.
Terminating a process, or executing a new program in the process,
destroys all the streams in the process. If descriptors linked to these
streams persist in other processes, their file positions become
undefined as a result. To prevent this, you must clean up the streams
before destroying them.
When you open channels (streams or descriptors) separately on a seekable
file, each channel has its own file position. These are called
independent channels.
The system handles each channel independently. Most of the time, this
is quite predictable and natural (especially for input): each channel
can read or write sequentially at its own place in the file. However,
if some of the channels are streams, you must take these precautions:
You should clean an output stream after use, before doing anything else
that might read or write from the same part of the file.
You should clean an input stream before reading data that may have been
modified using an independent channel. Otherwise, you might read
obsolete data that had been in the stream's buffer.
If you do output to one channel at the end of the file, this will
certainly leave the other independent channels positioned somewhere
before the new end. You cannot reliably set their file positions to the
new end of file before writing, because the file can always be extended
by another process between when you set the file position and when you
write the data. Instead, use an append-type descriptor or stream; they
always output at the current end of the file. In order to make the
end-of-file position accurate, you must clean the output channel you
were using, if it is a stream.
It's impossible for two channels to have separate file pointers for a
file that doesn't support random access. Thus, channels for reading or
writing such files are always linked, never independent. Append-type
channels are also always linked. For these channels, follow the rules
for linked channels; see 13.5.1 Linked Channels.
On the GNU system, you can clean up any stream with fclean:
Function: int fclean(FILE *stream)
Clean up the stream stream so that its buffer is empty. If
stream is doing output, force it out. If stream is doing
input, give the data in the buffer back to the system, arranging to
reread it.
On other systems, you can use fflush to clean a stream in most
cases.
You can skip the fclean or fflush if you know the stream
is already clean. A stream is clean whenever its buffer is empty. For
example, an unbuffered stream is always clean. An input stream that is
at end-of-file is clean. A line-buffered stream is clean when the last
character output was a newline.
There is one case in which cleaning a stream is impossible on most
systems. This is when the stream is doing input from a file that is not
random-access. Such streams typically read ahead, and when the file is
not random access, there is no way to give back the excess data already
read. When an input stream reads from a random-access file,
fflush does clean the stream, but leaves the file pointer at an
unpredictable place; you must set the file pointer before doing any
further I/O. On the GNU system, using fclean avoids both of
these problems.
Closing an output-only stream also does fflush, so this is a
valid way of cleaning an output stream. On the GNU system, closing an
input stream does fclean.
You need not clean a stream before using its descriptor for control
operations such as setting terminal modes; these operations don't affect
the file position and are not affected by it. You can use any
descriptor for these operations, and all channels are affected
simultaneously. However, text already "output" to a stream but still
buffered by the stream will be subject to the new terminal modes when
subsequently flushed. To make sure "past" output is covered by the
terminal settings that were in effect at the time, flush the output
streams for that terminal before setting the modes. See section 17.4 Terminal Modes.
Some applications may need to read or write data to multiple buffers,
which are separated in memory. Although this can be done easily enough
with multiple calls to read and write, it is inefficient
because there is overhead associated with each kernel call.
Instead, many platforms provide special high-speed primitives to perform
these scatter-gather operations in a single kernel call. The GNU C
library will provide an emulation on any system that lacks these
primitives, so they are not a portability threat. They are defined in
sys/uio.h.
These functions are controlled with arrays of iovec structures,
which describe the location and size of each buffer.
Data Type:struct iovec
The iovec structure describes a buffer. It contains two fields:
void *iov_base
Contains the address of a buffer.
size_t iov_len
Contains the length of the buffer.
Function: ssize_t readv(int filedes, const struct iovec *vector, int count)
The readv function reads data from filedes and scatters it
into the buffers described in vector, which is taken to be
count structures long. As each buffer is filled, data is sent to the
next.
Note that readv is not guaranteed to fill all the buffers.
It may stop at any point, for the same reasons read would.
The return value is a count of bytes (not buffers) read, 0
indicating end-of-file, or -1 indicating an error. The possible
errors are the same as in read.
Function: ssize_t writev(int filedes, const struct iovec *vector, int count)
The writev function gathers data from the buffers described in
vector, which is taken to be count structures long, and writes
them to filedes. As each buffer is written, it moves on to the
next.
Like readv, writev may stop midstream under the same
conditions write would.
The return value is a count of bytes written, or -1 indicating an
error. The possible errors are the same as in write.
Note that if the buffers are small (under about 1kB), high-level streams
may be easier to use than these functions. However, readv and
writev are more efficient when the individual buffers themselves
(as opposed to the total output), are large. In that case, a high-level
stream would not be able to cache the data effectively.
On modern operating systems, it is possible to mmap (pronounced
"em-map") a file to a region of memory. When this is done, the file can
be accessed just like an array in the program.
This is more efficient than read or write, as only the regions
of the file that a program actually accesses are loaded. Accesses to
not-yet-loaded parts of the mmapped region are handled in the same way as
swapped out pages.
Since mmapped pages can be stored back to their file when physical
memory is low, it is possible to mmap files orders of magnitude larger
than both the physical memory and swap space. The only limit is
address space. The theoretical limit is 4GB on a 32-bit machine -
however, the actual limit will be smaller since some areas will be
reserved for other purposes. If the LFS interface is used the file size
on 32-bit systems is not limited to 2GB (offsets are signed which
reduces the addressable area of 4GB by half); the full 64-bit are
available.
Memory mapping only works on entire pages of memory. Thus, addresses
for mapping must be page-aligned, and length values will be rounded up.
To determine the size of a page the machine uses one should use
Function: void * mmap(void *address, size_t length,int protect, int flags, int filedes, off_t offset)
The mmap function creates a new mapping, connected to bytes
(offset) to (offset + length - 1) in the file open on
filedes. A new reference for the file specified by filedes
is created, which is not removed by closing the file.
address gives a preferred starting address for the mapping.
NULL expresses no preference. Any previous mapping at that
address is automatically removed. The address you give may still be
changed, unless you use the MAP_FIXED flag.
protect contains flags that control what kind of access is
permitted. They include PROT_READ, PROT_WRITE, and
PROT_EXEC, which permit reading, writing, and execution,
respectively. Inappropriate access will cause a segfault (see section 24.2.1 Program Error Signals).
Note that most hardware designs cannot support write permission without
read permission, and many do not distinguish read and execute permission.
Thus, you may receive wider permissions than you ask for, and mappings of
write-only files may be denied even if you do not use PROT_READ.
flags contains flags that control the nature of the map.
One of MAP_SHARED or MAP_PRIVATE must be specified.
They include:
MAP_PRIVATE
This specifies that writes to the region should never be written back
to the attached file. Instead, a copy is made for the process, and the
region will be swapped normally if memory runs low. No other process will
see the changes.
Since private mappings effectively revert to ordinary memory
when written to, you must have enough virtual memory for a copy of
the entire mmapped region if you use this mode with PROT_WRITE.
MAP_SHARED
This specifies that writes to the region will be written back to the
file. Changes made will be shared immediately with other processes
mmaping the same file.
Note that actual writing may take place at any time. You need to use
msync, described below, if it is important that other processes
using conventional I/O get a consistent view of the file.
MAP_FIXED
This forces the system to use the exact mapping address specified in
address and fail if it can't.
MAP_ANONYMOUS
MAP_ANON
This flag tells the system to create an anonymous mapping, not connected
to a file. filedes and off are ignored, and the region is
initialized with zeros.
Anonymous maps are used as the basic primitive to extend the heap on some
systems. They are also useful to share data between multiple tasks
without creating a file.
On some systems using private anonymous mmaps is more efficient than using
malloc for large blocks. This is not an issue with the GNU C library,
as the included malloc automatically uses mmap where appropriate.
mmap returns the address of the new mapping, or -1 for an
error.
Possible errors include:
EINVAL
Either address was unusable, or inconsistent flags were
given.
EACCES
filedes was not open for the type of access specified in protect.
ENOMEM
Either there is not enough memory for the operation, or the process is
out of address space.
ENODEV
This file is of a type that doesn't support mapping.
ENOEXEC
The file is on a filesystem that doesn't support mapping.
Function: void * mmap64(void *address, size_t length,int protect, int flags, int filedes, off64_t offset)
The mmap64 function is equivalent to the mmap function but
the offset parameter is of type off64_t. On 32-bit systems
this allows the file associated with the filedes descriptor to be
larger than 2GB. filedes must be a descriptor returned from a
call to open64 or fopen64 and freopen64 where the
descriptor is retrieved with fileno.
When the sources are translated with _FILE_OFFSET_BITS == 64 this
function is actually available under the name mmap. I.e., the
new, extended API using 64 bit file sizes and offsets transparently
replaces the old API.
Function: int munmap(void *addr, size_t length)
munmap removes any memory maps from (addr) to (addr +
length). length should be the length of the mapping.
It is safe to unmap multiple mappings in one command, or include unmapped
space in the range. It is also possible to unmap only part of an existing
mapping. However, only entire pages can be removed. If length is not
an even number of pages, it will be rounded up.
It returns 0 for success and -1 for an error.
One error is possible:
EINVAL
The memory range given was outside the user mmap range or wasn't page
aligned.
Function: int msync(void *address, size_t length, int flags)
When using shared mappings, the kernel can write the file at any time
before the mapping is removed. To be certain data has actually been
written to the file and will be accessible to non-memory-mapped I/O, it
is necessary to use this function.
It operates on the region address to (address + length).
It may be used on part of a mapping or multiple mappings, however the
region given should not contain any unmapped space.
flags can contain some options:
MS_SYNC
This flag makes sure the data is actually written to disk.
Normally msync only makes sure that accesses to a file with
conventional I/O reflect the recent changes.
MS_ASYNC
This tells msync to begin the synchronization, but not to wait for
it to complete.
msync returns 0 for success and -1 for
error. Errors include:
EINVAL
An invalid region was given, or the flags were invalid.
EFAULT
There is no existing mapping in at least part of the given region.
This function can be used to change the size of an existing memory
area. address and length must cover a region entirely mapped
in the same mmap statement. A new mapping with the same
characteristics will be returned with the length new_length.
One option is possible, MREMAP_MAYMOVE. If it is given in
flags, the system may remove the existing mapping and create a new
one of the desired length in another location.
The address of the resulting mapping is returned, or -1. Possible
error codes include:
EFAULT
There is no existing mapping in at least part of the original region, or
the region covers two or more distinct mappings.
EINVAL
The address given is misaligned or inappropriate.
EAGAIN
The region has pages locked, and if extended it would exceed the
process's resource limit for locked pages. See section 22.2 Limiting Resource Usage.
ENOMEM
The region is private writable, and insufficient virtual memory is
available to extend it. Also, this error will occur if
MREMAP_MAYMOVE is not given and the extension would collide with
another mapped region.
This function is only available on a few systems. Except for performing
optional optimizations one should not rely on this function.
Not all file descriptors may be mapped. Sockets, pipes, and most devices
only allow sequential access and do not fit into the mapping abstraction.
In addition, some regular files may not be mmapable, and older kernels may
not support mapping at all. Thus, programs using mmap should
have a fallback method to use should it fail. See section `Mmap' in GNU Coding Standards.
Function: int madvise(void *addr, size_t length, int advice)
This function can be used to provide the system with advice about
the intended usage patterns of the memory region starting at addr
and extending length bytes.
The valid BSD values for advice are:
MADV_NORMAL
The region should receive no further special treatment.
MADV_RANDOM
The region will be accessed via random page references. The kernel
should page-in the minimal number of pages for each page fault.
MADV_SEQUENTIAL
The region will be accessed via sequential page references. This
may cause the kernel to aggressively read-ahead, expecting further
sequential references after any page fault within this region.
MADV_WILLNEED
The region will be needed. The pages within this region may
be pre-faulted in by the kernel.
MADV_DONTNEED
The region is no longer needed. The kernel may free these pages,
causing any changes to the pages to be lost, as well as swapped
out pages to be discarded.
The POSIX names are slightly different, but with the same meanings:
POSIX_MADV_NORMAL
This corresponds with BSD's MADV_NORMAL.
POSIX_MADV_RANDOM
This corresponds with BSD's MADV_RANDOM.
POSIX_MADV_SEQUENTIAL
This corresponds with BSD's MADV_SEQUENTIAL.
POSIX_MADV_WILLNEED
This corresponds with BSD's MADV_WILLNEED.
POSIX_MADV_DONTNEED
This corresponds with BSD's MADV_DONTNEED.
msync returns 0 for success and -1 for
error. Errors include:
EINVAL
An invalid region was given, or the advice was invalid.
EFAULT
There is no existing mapping in at least part of the given region.
Sometimes a program needs to accept input on multiple input channels
whenever input arrives. For example, some workstations may have devices
such as a digitizing tablet, function button box, or dial box that are
connected via normal asynchronous serial interfaces; good user interface
style requires responding immediately to input on any device. Another
example is a program that acts as a server to several other processes
via pipes or sockets.
You cannot normally use read for this purpose, because this
blocks the program until input is available on one particular file
descriptor; input on other channels won't wake it up. You could set
nonblocking mode and poll each file descriptor in turn, but this is very
inefficient.
A better solution is to use the select function. This blocks the
program until input or output is ready on a specified set of file
descriptors, or until a timer expires, whichever comes first. This
facility is declared in the header file `sys/types.h'.
In the case of a server socket (see section 16.9.2 Listening for Connections), we say that
"input" is available when there are pending connections that could be
accepted (see section 16.9.3 Accepting Connections). accept for server
sockets blocks and interacts with select just as read does
for normal input.
The file descriptor sets for the select function are specified
as fd_set objects. Here is the description of the data type
and some macros for manipulating these objects.
Data Type:fd_set
The fd_set data type represents file descriptor sets for the
select function. It is actually a bit array.
Macro: int FD_SETSIZE
The value of this macro is the maximum number of file descriptors that a
fd_set object can hold information about. On systems with a
fixed maximum number, FD_SETSIZE is at least that number. On
some systems, including GNU, there is no absolute limit on the number of
descriptors open, but this macro still has a constant value which
controls the number of bits in an fd_set; if you get a file
descriptor with a value as high as FD_SETSIZE, you cannot put
that descriptor into an fd_set.
Macro: void FD_ZERO(fd_set *set)
This macro initializes the file descriptor set set to be the
empty set.
Macro: void FD_SET(int filedes, fd_set *set)
This macro adds filedes to the file descriptor set set.
Macro: void FD_CLR(int filedes, fd_set *set)
This macro removes filedes from the file descriptor set set.
Macro: int FD_ISSET(int filedes, fd_set *set)
This macro returns a nonzero value (true) if filedes is a member
of the file descriptor set set, and zero (false) otherwise.
Next, here is the description of the select function itself.
The select function blocks the calling process until there is
activity on any of the specified sets of file descriptors, or until the
timeout period has expired.
The file descriptors specified by the read-fds argument are
checked to see if they are ready for reading; the write-fds file
descriptors are checked to see if they are ready for writing; and the
except-fds file descriptors are checked for exceptional
conditions. You can pass a null pointer for any of these arguments if
you are not interested in checking for that kind of condition.
A file descriptor is considered ready for reading if it is not at end of
file. A server socket is considered ready for reading if there is a
pending connection which can be accepted with accept;
see section 16.9.3 Accepting Connections. A client socket is ready for writing when
its connection is fully established; see section 16.9.1 Making a Connection.
"Exceptional conditions" does not mean errors--errors are reported
immediately when an erroneous system call is executed, and do not
constitute a state of the descriptor. Rather, they include conditions
such as the presence of an urgent message on a socket. (See section 16. Sockets,
for information on urgent messages.)
The select function checks only the first nfds file
descriptors. The usual thing is to pass FD_SETSIZE as the value
of this argument.
The timeout specifies the maximum time to wait. If you pass a
null pointer for this argument, it means to block indefinitely until one
of the file descriptors is ready. Otherwise, you should provide the
time in struct timeval format; see 21.4.2 High-Resolution Calendar. Specify zero as the time (a struct timeval containing
all zeros) if you want to find out which descriptors are ready without
waiting if none are ready.
The normal return value from select is the total number of ready file
descriptors in all of the sets. Each of the argument sets is overwritten
with information about the descriptors that are ready for the corresponding
operation. Thus, to see if a particular descriptor desc has input,
use FD_ISSET (desc, read-fds) after select returns.
If select returns because the timeout period expires, it returns
a value of zero.
Any signal will cause select to return immediately. So if your
program uses signals, you can't rely on select to keep waiting
for the full time specified. If you want to be sure of waiting for a
particular amount of time, you must check for EINTR and repeat
the select with a newly calculated timeout based on the current
time. See the example below. See also 24.5 Primitives Interrupted by Signals.
If an error occurs, select returns -1 and does not modify
the argument file descriptor sets. The following errno error
conditions are defined for this function:
EBADF
One of the file descriptor sets specified an invalid file descriptor.
The timeout argument is invalid; one of the components is negative
or too large.
Portability Note: The select function is a BSD Unix
feature.
Here is an example showing how you can use select to establish a
timeout period for reading from a file descriptor. The input_timeout
function blocks the calling process until input is available on the
file descriptor, or until the timeout period expires.
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/time.h>
int
input_timeout (int filedes, unsigned int seconds)
{
fd_set set;
struct timeval timeout;
/* Initialize the file descriptor set. */
FD_ZERO (&set);
FD_SET (filedes, &set);
/* Initialize the timeout data structure. */
timeout.tv_sec = seconds;
timeout.tv_usec = 0;
/* select returns 0 if timeout, 1 if input available, -1 if error. */
return TEMP_FAILURE_RETRY (select (FD_SETSIZE,
&set, NULL, NULL,
&timeout));
}
int
main (void)
{
fprintf (stderr, "select returned %d.\n",
input_timeout (STDIN_FILENO, 5));
return 0;
}
In most modern operating systems, the normal I/O operations are not
executed synchronously. I.e., even if a write system call
returns, this does not mean the data is actually written to the media,
e.g., the disk.
In situations where synchronization points are necessary, you can use
special functions which ensure that all operations finish before
they return.
Function: int sync(void)
A call to this function will not return as long as there is data which
has not been written to the device. All dirty buffers in the kernel will
be written and so an overall consistent system can be achieved (if no
other process in parallel writes data).
A prototype for sync can be found in `unistd.h'.
The return value is zero to indicate no error.
Programs more often want to ensure that data written to a given file is
committed, rather than all data in the system. For this, sync is overkill.
Function: int fsync(int fildes)
The fsync function can be used to make sure all data associated with
the open file fildes is written to the device associated with the
descriptor. The function call does not return unless all actions have
finished.
A prototype for fsync can be found in `unistd.h'.
This function is a cancellation point in multi-threaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time fsync is
called. If the thread gets canceled these resources stay allocated
until the program ends. To avoid this, calls to fsync should be
protected using cancellation handlers.
The return value of the function is zero if no error occurred. Otherwise
it is -1 and the global variable errno is set to the
following values:
EBADF
The descriptor fildes is not valid.
EINVAL
No synchronization is possible since the system does not implement this.
Sometimes it is not even necessary to write all data associated with a
file descriptor. E.g., in database files which do not change in size it
is enough to write all the file content data to the device.
Meta-information, like the modification time etc., are not that important
and leaving such information uncommitted does not prevent a successful
recovering of the file in case of a problem.
Function: int fdatasync(int fildes)
When a call to the fdatasync function returns, it is ensured
that all of the file data is written to the device. For all pending I/O
operations, the parts guaranteeing data integrity finished.
Not all systems implement the fdatasync operation. On systems
missing this functionality fdatasync is emulated by a call to
fsync since the performed actions are a superset of those
required by fdatasync.
The prototype for fdatasync is in `unistd.h'.
The return value of the function is zero if no error occurred. Otherwise
it is -1 and the global variable errno is set to the
following values:
EBADF
The descriptor fildes is not valid.
EINVAL
No synchronization is possible since the system does not implement this.
The POSIX.1b standard defines a new set of I/O operations which can
significantly reduce the time an application spends waiting at I/O. The
new functions allow a program to initiate one or more I/O operations and
then immediately resume normal work while the I/O operations are
executed in parallel. This functionality is available if the
`unistd.h' file defines the symbol _POSIX_ASYNCHRONOUS_IO.
These functions are part of the library with realtime functions named
`librt'. They are not actually part of the `libc' binary.
The implementation of these functions can be done using support in the
kernel (if available) or using an implementation based on threads at
userlevel. In the latter case it might be necessary to link applications
with the thread library `libpthread' in addition to `librt'.
All AIO operations operate on files which were opened previously. There
might be arbitrarily many operations running for one file. The
asynchronous I/O operations are controlled using a data structure named
struct aiocb (AIO control block). It is defined in
`aio.h' as follows.
Data Type:struct aiocb
The POSIX.1b standard mandates that the struct aiocb structure
contains at least the members described in the following table. There
might be more elements which are used by the implementation, but
depending upon these elements is not portable and is highly deprecated.
int aio_fildes
This element specifies the file descriptor to be used for the
operation. It must be a legal descriptor, otherwise the operation will
fail.
The device on which the file is opened must allow the seek operation.
I.e., it is not possible to use any of the AIO operations on devices
like terminals where an lseek call would lead to an error.
off_t aio_offset
This element specifies the offset in the file at which the operation (input
or output) is performed. Since the operations are carried out in arbitrary
order and more than one operation for one file descriptor can be
started, one cannot expect a current read/write position of the file
descriptor.
volatile void *aio_buf
This is a pointer to the buffer with the data to be written or the place
where the read data is stored.
size_t aio_nbytes
This element specifies the length of the buffer pointed to by aio_buf.
int aio_reqprio
If the platform has defined _POSIX_PRIORITIZED_IO and
_POSIX_PRIORITY_SCHEDULING, the AIO requests are
processed based on the current scheduling priority. The
aio_reqprio element can then be used to lower the priority of the
AIO operation.
struct sigevent aio_sigevent
This element specifies how the calling process is notified once the
operation terminates. If the sigev_notify element is
SIGEV_NONE, no notification is sent. If it is SIGEV_SIGNAL,
the signal determined by sigev_signo is sent. Otherwise,
sigev_notify must be SIGEV_THREAD. In this case, a thread
is created which starts executing the function pointed to by
sigev_notify_function.
int aio_lio_opcode
This element is only used by the lio_listio and
lio_listio64 functions. Since these functions allow an
arbitrary number of operations to start at once, and each operation can be
input or output (or nothing), the information must be stored in the
control block. The possible values are:
LIO_READ
Start a read operation. Read from the file at position
aio_offset and store the next aio_nbytes bytes in the
buffer pointed to by aio_buf.
LIO_WRITE
Start a write operation. Write aio_nbytes bytes starting at
aio_buf into the file starting at position aio_offset.
LIO_NOP
Do nothing for this control block. This value is useful sometimes when
an array of struct aiocb values contains holes, i.e., some of the
values must not be handled although the whole array is presented to the
lio_listio function.
When the sources are compiled using _FILE_OFFSET_BITS == 64 on a
32 bit machine, this type is in fact struct aiocb64, since the LFS
interface transparently replaces the struct aiocb definition.
For use with the AIO functions defined in the LFS, there is a similar type
defined which replaces the types of the appropriate members with larger
types but otherwise is equivalent to struct aiocb. Particularly,
all member names are the same.
Data Type:struct aiocb64
int aio_fildes
This element specifies the file descriptor which is used for the
operation. It must be a legal descriptor since otherwise the operation
fails for obvious reasons.
The device on which the file is opened must allow the seek operation.
I.e., it is not possible to use any of the AIO operations on devices
like terminals where an lseek call would lead to an error.
off64_t aio_offset
This element specifies at which offset in the file the operation (input
or output) is performed. Since the operation are carried in arbitrary
order and more than one operation for one file descriptor can be
started, one cannot expect a current read/write position of the file
descriptor.
volatile void *aio_buf
This is a pointer to the buffer with the data to be written or the place
where the read data is stored.
size_t aio_nbytes
This element specifies the length of the buffer pointed to by aio_buf.
int aio_reqprio
If for the platform _POSIX_PRIORITIZED_IO and
_POSIX_PRIORITY_SCHEDULING are defined the AIO requests are
processed based on the current scheduling priority. The
aio_reqprio element can then be used to lower the priority of the
AIO operation.
struct sigevent aio_sigevent
This element specifies how the calling process is notified once the
operation terminates. If the sigev_notify, element is
SIGEV_NONE no notification is sent. If it is SIGEV_SIGNAL,
the signal determined by sigev_signo is sent. Otherwise,
sigev_notify must be SIGEV_THREAD in which case a thread
which starts executing the function pointed to by
sigev_notify_function.
int aio_lio_opcode
This element is only used by the lio_listio and
[lio_listio64 functions. Since these functions allow an
arbitrary number of operations to start at once, and since each operation can be
input or output (or nothing), the information must be stored in the
control block. See the description of struct aiocb for a description
of the possible values.
When the sources are compiled using _FILE_OFFSET_BITS == 64 on a
32 bit machine, this type is available under the name struct
aiocb64, since the LFS transparently replaces the old interface.
This function initiates an asynchronous read operation. It
immediately returns after the operation was enqueued or when an
error was encountered.
The first aiocbp->aio_nbytes bytes of the file for which
aiocbp->aio_fildes is a descriptor are written to the buffer
starting at aiocbp->aio_buf. Reading starts at the absolute
position aiocbp->aio_offset in the file.
If prioritized I/O is supported by the platform the
aiocbp->aio_reqprio value is used to adjust the priority before
the request is actually enqueued.
The calling process is notified about the termination of the read
request according to the aiocbp->aio_sigevent value.
When aio_read returns, the return value is zero if no error
occurred that can be found before the process is enqueued. If such an
early error is found, the function returns -1 and sets
errno to one of the following values:
EAGAIN
The request was not enqueued due to (temporarily) exceeded resource
limitations.
ENOSYS
The aio_read function is not implemented.
EBADF
The aiocbp->aio_fildes descriptor is not valid. This condition
need not be recognized before enqueueing the request and so this error
might also be signaled asynchronously.
EINVAL
The aiocbp->aio_offset or aiocbp->aio_reqpiro value is
invalid. This condition need not be recognized before enqueueing the
request and so this error might also be signaled asynchronously.
If aio_read returns zero, the current status of the request
can be queried using aio_error and aio_return functions.
As long as the value returned by aio_error is EINPROGRESS
the operation has not yet completed. If aio_error returns zero,
the operation successfully terminated, otherwise the value is to be
interpreted as an error code. If the function terminated, the result of
the operation can be obtained using a call to aio_return. The
returned value is the same as an equivalent call to read would
have returned. Possible error codes returned by aio_error are:
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is in fact aio_read64 since the LFS interface transparently
replaces the normal implementation.
Function: int aio_read64(struct aiocb *aiocbp)
This function is similar to the aio_read function. The only
difference is that on 32 bit machines, the file descriptor should
be opened in the large file mode. Internally, aio_read64 uses
functionality equivalent to lseek64 (see section 13.3 Setting the File Position of a Descriptor) to position the file descriptor correctly for the reading,
as opposed to lseek functionality used in aio_read.
When the sources are compiled with _FILE_OFFSET_BITS == 64, this
function is available under the name aio_read and so transparently
replaces the interface for small files on 32 bit machines.
To write data asynchronously to a file, there exists an equivalent pair
of functions with a very similar interface.
Function: int aio_write(struct aiocb *aiocbp)
This function initiates an asynchronous write operation. The function
call immediately returns after the operation was enqueued or if before
this happens an error was encountered.
The first aiocbp->aio_nbytes bytes from the buffer starting at
aiocbp->aio_buf are written to the file for which
aiocbp->aio_fildes is an descriptor, starting at the absolute
position aiocbp->aio_offset in the file.
If prioritized I/O is supported by the platform, the
aiocbp->aio_reqprio value is used to adjust the priority before
the request is actually enqueued.
The calling process is notified about the termination of the read
request according to the aiocbp->aio_sigevent value.
When aio_write returns, the return value is zero if no error
occurred that can be found before the process is enqueued. If such an
early error is found the function returns -1 and sets
errno to one of the following values.
EAGAIN
The request was not enqueued due to (temporarily) exceeded resource
limitations.
ENOSYS
The aio_write function is not implemented.
EBADF
The aiocbp->aio_fildes descriptor is not valid. This condition
may not be recognized before enqueueing the request, and so this error
might also be signaled asynchronously.
EINVAL
The aiocbp->aio_offset or aiocbp->aio_reqprio value is
invalid. This condition may not be recognized before enqueueing the
request and so this error might also be signaled asynchronously.
In the case aio_write returns zero, the current status of the
request can be queried using aio_error and aio_return
functions. As long as the value returned by aio_error is
EINPROGRESS the operation has not yet completed. If
aio_error returns zero, the operation successfully terminated,
otherwise the value is to be interpreted as an error code. If the
function terminated, the result of the operation can be get using a call
to aio_return. The returned value is the same as an equivalent
call to read would have returned. Possible error codes returned
by aio_error are:
When the sources are compiled with _FILE_OFFSET_BITS == 64, this
function is in fact aio_write64 since the LFS interface transparently
replaces the normal implementation.
Function: int aio_write64(struct aiocb *aiocbp)
This function is similar to the aio_write function. The only
difference is that on 32 bit machines the file descriptor should
be opened in the large file mode. Internally aio_write64 uses
functionality equivalent to lseek64 (see section 13.3 Setting the File Position of a Descriptor) to position the file descriptor correctly for the writing,
as opposed to lseek functionality used in aio_write.
When the sources are compiled with _FILE_OFFSET_BITS == 64, this
function is available under the name aio_write and so transparently
replaces the interface for small files on 32 bit machines.
Besides these functions with the more or less traditional interface,
POSIX.1b also defines a function which can initiate more than one
operation at a time, and which can handle freely mixed read and write
operations. It is therefore similar to a combination of readv and
writev.
Function: int lio_listio(int mode, struct aiocb *const list[], int nent, struct sigevent *sig)
The lio_listio function can be used to enqueue an arbitrary
number of read and write requests at one time. The requests can all be
meant for the same file, all for different files or every solution in
between.
lio_listio gets the nent requests from the array pointed to
by list. The operation to be performed is determined by the
aio_lio_opcode member in each element of list. If this
field is LIO_READ a read operation is enqueued, similar to a call
of aio_read for this element of the array (except that the way
the termination is signalled is different, as we will see below). If
the aio_lio_opcode member is LIO_WRITE a write operation
is enqueued. Otherwise the aio_lio_opcode must be LIO_NOP
in which case this element of list is simply ignored. This
"operation" is useful in situations where one has a fixed array of
struct aiocb elements from which only a few need to be handled at
a time. Another situation is where the lio_listio call was
canceled before all requests are processed (see section 13.10.4 Cancellation of AIO Operations) and the remaining requests have to be reissued.
The other members of each element of the array pointed to by
list must have values suitable for the operation as described in
the documentation for aio_read and aio_write above.
The mode argument determines how lio_listio behaves after
having enqueued all the requests. If mode is LIO_WAIT it
waits until all requests terminated. Otherwise mode must be
LIO_NOWAIT and in this case the function returns immediately after
having enqueued all the requests. In this case the caller gets a
notification of the termination of all requests according to the
sig parameter. If sig is NULL no notification is
send. Otherwise a signal is sent or a thread is started, just as
described in the description for aio_read or aio_write.
If mode is LIO_WAIT, the return value of lio_listio
is 0 when all requests completed successfully. Otherwise the
function return -1 and errno is set accordingly. To find
out which request or requests failed one has to use the aio_error
function on all the elements of the array list.
In case mode is LIO_NOWAIT, the function returns 0 if
all requests were enqueued correctly. The current state of the requests
can be found using aio_error and aio_return as described
above. If lio_listio returns -1 in this mode, the
global variable errno is set accordingly. If a request did not
yet terminate, a call to aio_error returns EINPROGRESS. If
the value is different, the request is finished and the error value (or
0) is returned and the result of the operation can be retrieved
using aio_return.
Possible values for errno are:
EAGAIN
The resources necessary to queue all the requests are not available at
the moment. The error status for each element of list must be
checked to determine which request failed.
Another reason could be that the system wide limit of AIO requests is
exceeded. This cannot be the case for the implementation on GNU systems
since no arbitrary limits exist.
EINVAL
The mode parameter is invalid or nent is larger than
AIO_LISTIO_MAX.
EIO
One or more of the request's I/O operations failed. The error status of
each request should be checked to determine which one failed.
ENOSYS
The lio_listio function is not supported.
If the mode parameter is LIO_NOWAIT and the caller cancels
a request, the error status for this request returned by
aio_error is ECANCELED.
When the sources are compiled with _FILE_OFFSET_BITS == 64, this
function is in fact lio_listio64 since the LFS interface
transparently replaces the normal implementation.
Function: int lio_listio64(int mode, struct aiocb *const list, int nent, struct sigevent *sig)
This function is similar to the lio_listio function. The only
difference is that on 32 bit machines, the file descriptor should
be opened in the large file mode. Internally, lio_listio64 uses
functionality equivalent to lseek64 (see section 13.3 Setting the File Position of a Descriptor) to position the file descriptor correctly for the reading or
writing, as opposed to lseek functionality used in
lio_listio.
When the sources are compiled with _FILE_OFFSET_BITS == 64, this
function is available under the name lio_listio and so
transparently replaces the interface for small files on 32 bit
machines.
As already described in the documentation of the functions in the last
section, it must be possible to get information about the status of an I/O
request. When the operation is performed truly asynchronously (as with
aio_read and aio_write and with lio_listio when the
mode is LIO_NOWAIT), one sometimes needs to know whether a
specific request already terminated and if so, what the result was.
The following two functions allow you to get this kind of information.
Function: int aio_error(const struct aiocb *aiocbp)
This function determines the error state of the request described by the
struct aiocb variable pointed to by aiocbp. If the
request has not yet terminated the value returned is always
EINPROGRESS. Once the request has terminated the value
aio_error returns is either 0 if the request completed
successfully or it returns the value which would be stored in the
errno variable if the request would have been done using
read, write, or fsync.
The function can return ENOSYS if it is not implemented. It
could also return EINVAL if the aiocbp parameter does not
refer to an asynchronous operation whose return status is not yet known.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is in fact aio_error64 since the LFS interface
transparently replaces the normal implementation.
Function: int aio_error64(const struct aiocb64 *aiocbp)
This function is similar to aio_error with the only difference
that the argument is a reference to a variable of type struct
aiocb64.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is available under the name aio_error and so
transparently replaces the interface for small files on 32 bit
machines.
This function can be used to retrieve the return status of the operation
carried out by the request described in the variable pointed to by
aiocbp. As long as the error status of this request as returned
by aio_error is EINPROGRESS the return of this function is
undefined.
Once the request is finished this function can be used exactly once to
retrieve the return value. Following calls might lead to undefined
behavior. The return value itself is the value which would have been
returned by the read, write, or fsync call.
The function can return ENOSYS if it is not implemented. It
could also return EINVAL if the aiocbp parameter does not
refer to an asynchronous operation whose return status is not yet known.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is in fact aio_return64 since the LFS interface
transparently replaces the normal implementation.
Function: int aio_return64(const struct aiocb64 *aiocbp)
This function is similar to aio_return with the only difference
that the argument is a reference to a variable of type struct
aiocb64.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is available under the name aio_return and so
transparently replaces the interface for small files on 32 bit
machines.
When dealing with asynchronous operations it is sometimes necessary to
get into a consistent state. This would mean for AIO that one wants to
know whether a certain request or a group of request were processed.
This could be done by waiting for the notification sent by the system
after the operation terminated, but this sometimes would mean wasting
resources (mainly computation time). Instead POSIX.1b defines two
functions which will help with most kinds of consistency.
The aio_fsync and aio_fsync64 functions are only available
if the symbol _POSIX_SYNCHRONIZED_IO is defined in `unistd.h'.
Function: int aio_fsync(int op, struct aiocb *aiocbp)
Calling this function forces all I/O operations operating queued at the
time of the function call operating on the file descriptor
aiocbp->aio_fildes into the synchronized I/O completion state
(see section 13.9 Synchronizing I/O operations). The aio_fsync function returns
immediately but the notification through the method described in
aiocbp->aio_sigevent will happen only after all requests for this
file descriptor have terminated and the file is synchronized. This also
means that requests for this very same file descriptor which are queued
after the synchronization request are not affected.
If op is O_DSYNC the synchronization happens as with a call
to fdatasync. Otherwise op should be O_SYNC and
the synchronization happens as with fsync.
As long as the synchronization has not happened, a call to
aio_error with the reference to the object pointed to by
aiocbp returns EINPROGRESS. Once the synchronization is
done aio_error return 0 if the synchronization was not
successful. Otherwise the value returned is the value to which the
fsync or fdatasync function would have set the
errno variable. In this case nothing can be assumed about the
consistency for the data written to this file descriptor.
The return value of this function is 0 if the request was
successfully enqueued. Otherwise the return value is -1 and
errno is set to one of the following values:
EAGAIN
The request could not be enqueued due to temporary lack of resources.
EBADF
The file descriptor aiocbp->aio_fildes is not valid or not open
for writing.
EINVAL
The implementation does not support I/O synchronization or the op
parameter is other than O_DSYNC and O_SYNC.
ENOSYS
This function is not implemented.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is in fact aio_return64 since the LFS interface
transparently replaces the normal implementation.
Function: int aio_fsync64(int op, struct aiocb64 *aiocbp)
This function is similar to aio_fsync with the only difference
that the argument is a reference to a variable of type struct
aiocb64.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is available under the name aio_fsync and so
transparently replaces the interface for small files on 32 bit
machines.
Another method of synchronization is to wait until one or more requests of a
specific set terminated. This could be achieved by the aio_*
functions to notify the initiating process about the termination but in
some situations this is not the ideal solution. In a program which
constantly updates clients somehow connected to the server it is not
always the best solution to go round robin since some connections might
be slow. On the other hand letting the aio_* function notify the
caller might also be not the best solution since whenever the process
works on preparing data for on client it makes no sense to be
interrupted by a notification since the new client will not be handled
before the current client is served. For situations like this
aio_suspend should be used.
Function: int aio_suspend(const struct aiocb *const list[], int nent, const struct timespec *timeout)
When calling this function, the calling thread is suspended until at
least one of the requests pointed to by the nent elements of the
array list has completed. If any of the requests has already
completed at the time aio_suspend is called, the function returns
immediately. Whether a request has terminated or not is determined by
comparing the error status of the request with EINPROGRESS. If
an element of list is NULL, the entry is simply ignored.
If no request has finished, the calling process is suspended. If
timeout is NULL, the process is not woken until a request
has finished. If timeout is not NULL, the process remains
suspended at least as long as specified in timeout. In this case,
aio_suspend returns with an error.
The return value of the function is 0 if one or more requests
from the list have terminated. Otherwise the function returns
-1 and errno is set to one of the following values:
EAGAIN
None of the requests from the list completed in the time specified
by timeout.
EINTR
A signal interrupted the aio_suspend function. This signal might
also be sent by the AIO implementation while signalling the termination
of one of the requests.
ENOSYS
The aio_suspend function is not implemented.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is in fact aio_suspend64 since the LFS interface
transparently replaces the normal implementation.
Function: int aio_suspend64(const struct aiocb64 *const list[], int nent, const struct timespec *timeout)
This function is similar to aio_suspend with the only difference
that the argument is a reference to a variable of type struct
aiocb64.
When the sources are compiled with _FILE_OFFSET_BITS == 64 this
function is available under the name aio_suspend and so
transparently replaces the interface for small files on 32 bit
machines.
When one or more requests are asynchronously processed, it might be
useful in some situations to cancel a selected operation, e.g., if it
becomes obvious that the written data is no longer accurate and would
have to be overwritten soon. As an example, assume an application, which
writes data in files in a situation where new incoming data would have
to be written in a file which will be updated by an enqueued request.
The POSIX AIO implementation provides such a function, but this function
is not capable of forcing the cancellation of the request. It is up to the
implementation to decide whether it is possible to cancel the operation
or not. Therefore using this function is merely a hint.
Function: int aio_cancel(int fildes, struct aiocb *aiocbp)
The aio_cancel function can be used to cancel one or more
outstanding requests. If the aiocbp parameter is NULL, the
function tries to cancel all of the outstanding requests which would process
the file descriptor fildes (i.e., whose aio_fildes member
is fildes). If aiocbp is not NULL, aio_cancel
attempts to cancel the specific request pointed to by aiocbp.
For requests which were successfully canceled, the normal notification
about the termination of the request should take place. I.e., depending
on the struct sigevent object which controls this, nothing
happens, a signal is sent or a thread is started. If the request cannot
be canceled, it terminates the usual way after performing the operation.
After a request is successfully canceled, a call to aio_error with
a reference to this request as the parameter will return
ECANCELED and a call to aio_return will return -1.
If the request wasn't canceled and is still running the error status is
still EINPROGRESS.
The return value of the function is AIO_CANCELED if there were
requests which haven't terminated and which were successfully canceled.
If there is one or more requests left which couldn't be canceled, the
return value is AIO_NOTCANCELED. In this case aio_error
must be used to find out which of the, perhaps multiple, requests (in
aiocbp is NULL) weren't successfully canceled. If all
requests already terminated at the time aio_cancel is called the
return value is AIO_ALLDONE.
If an error occurred during the execution of aio_cancel the
function returns -1 and sets errno to one of the following
values.
EBADF
The file descriptor fildes is not valid.
ENOSYS
aio_cancel is not implemented.
When the sources are compiled with _FILE_OFFSET_BITS == 64, this
function is in fact aio_cancel64 since the LFS interface
transparently replaces the normal implementation.
Function: int aio_cancel64(int fildes, struct aiocb64 *aiocbp)
This function is similar to aio_cancel with the only difference
that the argument is a reference to a variable of type struct
aiocb64.
When the sources are compiled with _FILE_OFFSET_BITS == 64, this
function is available under the name aio_cancel and so
transparently replaces the interface for small files on 32 bit
machines.
The POSIX standard does not specify how the AIO functions are
implemented. They could be system calls, but it is also possible to
emulate them at userlevel.
At the point of this writing, the available implementation is a userlevel
implementation which uses threads for handling the enqueued requests.
While this implementation requires making some decisions about
limitations, hard limitations are something which is best avoided
in the GNU C library. Therefore, the GNU C library provides a means
for tuning the AIO implementation according to the individual use.
Data Type:struct aioinit
This data type is used to pass the configuration or tunable parameters
to the implementation. The program has to initialize the members of
this struct and pass it to the implementation using the aio_init
function.
int aio_threads
This member specifies the maximal number of threads which may be used
at any one time.
int aio_num
This number provides an estimate on the maximal number of simultaneously
enqueued requests.
This function must be called before any other AIO function. Calling it
is completely voluntary, as it is only meant to help the AIO
implementation perform better.
Before calling the aio_init, function the members of a variable of
type struct aioinit must be initialized. Then a reference to
this variable is passed as the parameter to aio_init which itself
may or may not pay attention to the hints.
The function has no return value and no error cases are defined. It is
a extension which follows a proposal from the SGI implementation in
Irix 6. It is not covered by POSIX.1b or Unix98.
This section describes how you can perform various other operations on
file descriptors, such as inquiring about or setting flags describing
the status of the file descriptor, manipulating record locks, and the
like. All of these operations are performed by the function fcntl.
The second argument to the fcntl function is a command that
specifies which operation to perform. The function and macros that name
various flags that are used with it are declared in the header file
`fcntl.h'. Many of these flags are also used by the open
function; see 13.1 Opening and Closing Files.
Function: int fcntl(int filedes, int command, ...)
The fcntl function performs the operation specified by
command on the file descriptor filedes. Some commands
require additional arguments to be supplied. These additional arguments
and the return value and error conditions are given in the detailed
descriptions of the individual commands.
Briefly, here is a list of what the various commands are.
F_DUPFD
Duplicate the file descriptor (return another file descriptor pointing
to the same open file). See section 13.12 Duplicating Descriptors.
This function is a cancellation point in multi-threaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time fcntl is
called. If the thread gets canceled these resources stay allocated
until the program ends. To avoid this calls to fcntl should be
protected using cancellation handlers.
You can duplicate a file descriptor, or allocate another file
descriptor that refers to the same open file as the original. Duplicate
descriptors share one file position and one set of file status flags
(see section 13.14 File Status Flags), but each has its own set of file descriptor
flags (see section 13.13 File Descriptor Flags).
The major use of duplicating a file descriptor is to implement
redirection of input or output: that is, to change the
file or pipe that a particular file descriptor corresponds to.
You can perform this operation using the fcntl function with the
F_DUPFD command, but there are also convenient functions
dup and dup2 for duplicating descriptors.
The fcntl function and flags are declared in `fcntl.h',
while prototypes for dup and dup2 are in the header file
`unistd.h'.
Function: int dup(int old)
This function copies descriptor old to the first available
descriptor number (the first number not currently open). It is
equivalent to fcntl (old, F_DUPFD, 0).
Function: int dup2(int old, int new)
This function copies the descriptor old to descriptor number
new.
If old is an invalid descriptor, then dup2 does nothing; it
does not close new. Otherwise, the new duplicate of old
replaces any previous meaning of descriptor new, as if new
were closed first.
If old and new are different numbers, and old is a
valid descriptor number, then dup2 is equivalent to:
close (new);
fcntl (old, F_DUPFD, new)
However, dup2 does this atomically; there is no instant in the
middle of calling dup2 at which new is closed and not yet a
duplicate of old.
Macro: int F_DUPFD
This macro is used as the command argument to fcntl, to
copy the file descriptor given as the first argument.
The form of the call in this case is:
fcntl (old, F_DUPFD, next-filedes)
The next-filedes argument is of type int and specifies that
the file descriptor returned should be the next available one greater
than or equal to this value.
The return value from fcntl with this command is normally the value
of the new file descriptor. A return value of -1 indicates an
error. The following errno error conditions are defined for
this command:
EBADF
The old argument is invalid.
EINVAL
The next-filedes argument is invalid.
EMFILE
There are no more file descriptors available--your program is already
using the maximum. In BSD and GNU, the maximum is controlled by a
resource limit that can be changed; see section 22.2 Limiting Resource Usage, for
more information about the RLIMIT_NOFILE limit.
ENFILE is not a possible error code for dup2 because
dup2 does not create a new opening of a file; duplicate
descriptors do not count toward the limit which ENFILE
indicates. EMFILE is possible because it refers to the limit on
distinct descriptor numbers in use in one process.
Here is an example showing how to use dup2 to do redirection.
Typically, redirection of the standard streams (like stdin) is
done by a shell or shell-like program before calling one of the
exec functions (see section 26.5 Executing a File) to execute a new
program in a child process. When the new program is executed, it
creates and initializes the standard streams to point to the
corresponding file descriptors, before its main function is
invoked.
So, to redirect standard input to a file, the shell could do something
like:
File descriptor flags are miscellaneous attributes of a file
descriptor. These flags are associated with particular file
descriptors, so that if you have created duplicate file descriptors
from a single opening of a file, each descriptor has its own set of flags.
Currently there is just one file descriptor flag: FD_CLOEXEC,
which causes the descriptor to be closed if you use any of the
exec... functions (see section 26.5 Executing a File).
The symbols in this section are defined in the header file
`fcntl.h'.
Macro: int F_GETFD
This macro is used as the command argument to fcntl, to
specify that it should return the file descriptor flags associated
with the filedes argument.
The normal return value from fcntl with this command is a
nonnegative number which can be interpreted as the bitwise OR of the
individual flags (except that currently there is only one flag to use).
In case of an error, fcntl returns -1. The following
errno error conditions are defined for this command:
EBADF
The filedes argument is invalid.
Macro: int F_SETFD
This macro is used as the command argument to fcntl, to
specify that it should set the file descriptor flags associated with the
filedes argument. This requires a third int argument to
specify the new flags, so the form of the call is:
fcntl (filedes, F_SETFD, new-flags)
The normal return value from fcntl with this command is an
unspecified value other than -1, which indicates an error.
The flags and error conditions are the same as for the F_GETFD
command.
The following macro is defined for use as a file descriptor flag with
the fcntl function. The value is an integer constant usable
as a bit mask value.
Macro: int FD_CLOEXEC
This flag specifies that the file descriptor should be closed when
an exec function is invoked; see 26.5 Executing a File. When
a file descriptor is allocated (as with open or dup),
this bit is initially cleared on the new file descriptor, meaning that
descriptor will survive into the new program after exec.
If you want to modify the file descriptor flags, you should get the
current flags with F_GETFD and modify the value. Don't assume
that the flags listed here are the only ones that are implemented; your
program may be run years from now and more flags may exist then. For
example, here is a function to set or clear the flag FD_CLOEXEC
without altering any other flags:
/* Set the FD_CLOEXEC flag of desc if value is nonzero,
or clear the flag if value is 0.
Return 0 on success, or -1 on error with errno set. */
int
set_cloexec_flag (int desc, int value)
{
int oldflags = fcntl (desc, F_GETFD, 0);
/* If reading the flags failed, return error indication now.
if (oldflags < 0)
return oldflags;
/* Set just the flag we want to set. */
if (value != 0)
oldflags |= FD_CLOEXEC;
else
oldflags &= ~FD_CLOEXEC;
/* Store modified flag word in the descriptor. */
return fcntl (desc, F_SETFD, oldflags);
}
File status flags are used to specify attributes of the opening of a
file. Unlike the file descriptor flags discussed in 13.13 File Descriptor Flags, the file status flags are shared by duplicated file descriptors
resulting from a single opening of the file. The file status flags are
specified with the flags argument to open;
see section 13.1 Opening and Closing Files.
File status flags fall into three categories, which are described in the
following sections.
13.14.1 File Access Modes, specify what type of access is allowed to the
file: reading, writing, or both. They are set by open and are
returned by fcntl, but cannot be changed.
13.14.2 Open-time Flags, control details of what open will do.
These flags are not preserved after the open call.
13.14.3 I/O Operating Modes, affect how operations such as read and
write are done. They are set by open, and can be fetched or
changed with fcntl.
The symbols in this section are defined in the header file
`fcntl.h'.
The file access modes allow a file descriptor to be used for reading,
writing, or both. (In the GNU system, they can also allow none of these,
and allow execution of the file as a program.) The access modes are chosen
when the file is opened, and never change.
Macro: int O_RDONLY
Open the file for read access.
Macro: int O_WRONLY
Open the file for write access.
Macro: int O_RDWR
Open the file for both reading and writing.
In the GNU system (and not in other systems), O_RDONLY and
O_WRONLY are independent bits that can be bitwise-ORed together,
and it is valid for either bit to be set or clear. This means that
O_RDWR is the same as O_RDONLY|O_WRONLY. A file access
mode of zero is permissible; it allows no operations that do input or
output to the file, but does allow other operations such as
fchmod. On the GNU system, since "read-only" or "write-only"
is a misnomer, `fcntl.h' defines additional names for the file
access modes. These names are preferred when writing GNU-specific code.
But most programs will want to be portable to other POSIX.1 systems and
should use the POSIX.1 names above instead.
Macro: int O_READ
Open the file for reading. Same as O_RDWR; only defined on GNU.
Macro: int O_WRITE
Open the file for reading. Same as O_WRONLY; only defined on GNU.
Macro: int O_EXEC
Open the file for executing. Only defined on GNU.
To determine the file access mode with fcntl, you must extract
the access mode bits from the retrieved file status flags. In the GNU
system, you can just test the O_READ and O_WRITE bits in
the flags word. But in other POSIX.1 systems, reading and writing
access modes are not stored as distinct bit flags. The portable way to
extract the file access mode bits is with O_ACCMODE.
Macro: int O_ACCMODE
This macro stands for a mask that can be bitwise-ANDed with the file
status flag value to produce a value representing the file access mode.
The mode will be O_RDONLY, O_WRONLY, or O_RDWR.
(In the GNU system it could also be zero, and it never includes the
O_EXEC bit.)
The open-time flags specify options affecting how open will behave.
These options are not preserved once the file is open. The exception to
this is O_NONBLOCK, which is also an I/O operating mode and so it
is saved. See section 13.1 Opening and Closing Files, for how to call
open.
There are two sorts of options specified by open-time flags.
File name translation flags affect how open looks up the
file name to locate the file, and whether the file can be created.
Open-time action flags specify extra operations that open will
perform on the file once it is open.
Here are the file name translation flags.
Macro: int O_CREAT
If set, the file will be created if it doesn't already exist.
Macro: int O_EXCL
If both O_CREAT and O_EXCL are set, then open fails
if the specified file already exists. This is guaranteed to never
clobber an existing file.
Macro: int O_NONBLOCK
This prevents open from blocking for a "long time" to open the
file. This is only meaningful for some kinds of files, usually devices
such as serial ports; when it is not meaningful, it is harmless and
ignored. Often opening a port to a modem blocks until the modem reports
carrier detection; if O_NONBLOCK is specified, open will
return immediately without a carrier.
Note that the O_NONBLOCK flag is overloaded as both an I/O operating
mode and a file name translation flag. This means that specifying
O_NONBLOCK in open also sets nonblocking I/O mode;
see section 13.14.3 I/O Operating Modes. To open the file without blocking but do normal
I/O that blocks, you must call open with O_NONBLOCK set and
then call fcntl to turn the bit off.
Macro: int O_NOCTTY
If the named file is a terminal device, don't make it the controlling
terminal for the process. See section 27. Job Control, for information about
what it means to be the controlling terminal.
In the GNU system and 4.4 BSD, opening a file never makes it the
controlling terminal and O_NOCTTY is zero. However, other
systems may use a nonzero value for O_NOCTTY and set the
controlling terminal when you open a file that is a terminal device; so
to be portable, use O_NOCTTY when it is important to avoid this.
The following three file name translation flags exist only in the GNU system.
Macro: int O_IGNORE_CTTY
Do not recognize the named file as the controlling terminal, even if it
refers to the process's existing controlling terminal device. Operations
on the new file descriptor will never induce job control signals.
See section 27. Job Control.
Macro: int O_NOLINK
If the named file is a symbolic link, open the link itself instead of
the file it refers to. (fstat on the new file descriptor will
return the information returned by lstat on the link's name.)
Macro: int O_NOTRANS
If the named file is specially translated, do not invoke the translator.
Open the bare file the translator itself sees.
The open-time action flags tell open to do additional operations
which are not really related to opening the file. The reason to do them
as part of open instead of in separate calls is that open
can do them atomically.
Macro: int O_TRUNC
Truncate the file to zero length. This option is only useful for
regular files, not special files such as directories or FIFOs. POSIX.1
requires that you open the file for writing to use O_TRUNC. In
BSD and GNU you must have permission to write the file to truncate it,
but you need not open for write access.
This is the only open-time action flag specified by POSIX.1. There is
no good reason for truncation to be done by open, instead of by
calling ftruncate afterwards. The O_TRUNC flag existed in
Unix before ftruncate was invented, and is retained for backward
compatibility.
The remaining operating modes are BSD extensions. They exist only
on some systems. On other systems, these macros are not defined.
Macro: int O_SHLOCK
Acquire a shared lock on the file, as with flock.
See section 13.15 File Locks.
If O_CREAT is specified, the locking is done atomically when
creating the file. You are guaranteed that no other process will get
the lock on the new file first.
Macro: int O_EXLOCK
Acquire an exclusive lock on the file, as with flock.
See section 13.15 File Locks. This is atomic like O_SHLOCK.
The operating modes affect how input and output operations using a file
descriptor work. These flags are set by open and can be fetched
and changed with fcntl.
Macro: int O_APPEND
The bit that enables append mode for the file. If set, then all
write operations write the data at the end of the file, extending
it, regardless of the current file position. This is the only reliable
way to append to a file. In append mode, you are guaranteed that the
data you write will always go to the current end of the file, regardless
of other processes writing to the file. Conversely, if you simply set
the file position to the end of file and write, then another process can
extend the file after you set the file position but before you write,
resulting in your data appearing someplace before the real end of file.
Macro: int O_NONBLOCK
The bit that enables nonblocking mode for the file. If this bit is set,
read requests on the file can return immediately with a failure
status if there is no input immediately available, instead of blocking.
Likewise, write requests can also return immediately with a
failure status if the output can't be written immediately.
Note that the O_NONBLOCK flag is overloaded as both an I/O
operating mode and a file name translation flag; see section 13.14.2 Open-time Flags.
Macro: int O_NDELAY
This is an obsolete name for O_NONBLOCK, provided for
compatibility with BSD. It is not defined by the POSIX.1 standard.
The remaining operating modes are BSD and GNU extensions. They exist only
on some systems. On other systems, these macros are not defined.
Macro: int O_ASYNC
The bit that enables asynchronous input mode. If set, then SIGIO
signals will be generated when input is available. See section 13.16 Interrupt-Driven Input.
Asynchronous input mode is a BSD feature.
Macro: int O_FSYNC
The bit that enables synchronous writing for the file. If set, each
write call will make sure the data is reliably stored on disk before
returning.
Synchronous writing is a BSD feature.
Macro: int O_SYNC
This is another name for O_FSYNC. They have the same value.
Macro: int O_NOATIME
If this bit is set, read will not update the access time of the
file. See section 14.9.9 File Times. This is used by programs that do backups, so
that backing a file up does not count as reading it.
Only the owner of the file or the superuser may use this bit.
The fcntl function can fetch or change file status flags.
Macro: int F_GETFL
This macro is used as the command argument to fcntl, to
read the file status flags for the open file with descriptor
filedes.
The normal return value from fcntl with this command is a
nonnegative number which can be interpreted as the bitwise OR of the
individual flags. Since the file access modes are not single-bit values,
you can mask off other bits in the returned flags with O_ACCMODE
to compare them.
In case of an error, fcntl returns -1. The following
errno error conditions are defined for this command:
EBADF
The filedes argument is invalid.
Macro: int F_SETFL
This macro is used as the command argument to fcntl, to set
the file status flags for the open file corresponding to the
filedes argument. This command requires a third int
argument to specify the new flags, so the call looks like this:
fcntl (filedes, F_SETFL, new-flags)
You can't change the access mode for the file in this way; that is,
whether the file descriptor was opened for reading or writing.
The normal return value from fcntl with this command is an
unspecified value other than -1, which indicates an error. The
error conditions are the same as for the F_GETFL command.
If you want to modify the file status flags, you should get the current
flags with F_GETFL and modify the value. Don't assume that the
flags listed here are the only ones that are implemented; your program
may be run years from now and more flags may exist then. For example,
here is a function to set or clear the flag O_NONBLOCK without
altering any other flags:
/* Set the O_NONBLOCK flag of desc if value is nonzero,
or clear the flag if value is 0.
Return 0 on success, or -1 on error with errno set. */
int
set_nonblock_flag (int desc, int value)
{
int oldflags = fcntl (desc, F_GETFL, 0);
/* If reading the flags failed, return error indication now. */
if (oldflags == -1)
return -1;
/* Set just the flag we want to set. */
if (value != 0)
oldflags |= O_NONBLOCK;
else
oldflags &= ~O_NONBLOCK;
/* Store modified flag word in the descriptor. */
return fcntl (desc, F_SETFL, oldflags);
}
The remaining fcntl commands are used to support record
locking, which permits multiple cooperating programs to prevent each
other from simultaneously accessing parts of a file in error-prone
ways.
An exclusive or write lock gives a process exclusive access
for writing to the specified part of the file. While a write lock is in
place, no other process can lock that part of the file.
A shared or read lock prohibits any other process from
requesting a write lock on the specified part of the file. However,
other processes can request read locks.
The read and write functions do not actually check to see
whether there are any locks in place. If you want to implement a
locking protocol for a file shared by multiple processes, your application
must do explicit fcntl calls to request and clear locks at the
appropriate points.
Locks are associated with processes. A process can only have one kind
of lock set for each byte of a given file. When any file descriptor for
that file is closed by the process, all of the locks that process holds
on that file are released, even if the locks were made using other
descriptors that remain open. Likewise, locks are released when a
process exits, and are not inherited by child processes created using
fork (see section 26.4 Creating a Process).
When making a lock, use a struct flock to specify what kind of
lock and where. This data type and the associated macros for the
fcntl function are declared in the header file `fcntl.h'.
Data Type:struct flock
This structure is used with the fcntl function to describe a file
lock. It has these members:
short int l_type
Specifies the type of the lock; one of F_RDLCK, F_WRLCK, or
F_UNLCK.
short int l_whence
This corresponds to the whence argument to fseek or
lseek, and specifies what the offset is relative to. Its value
can be one of SEEK_SET, SEEK_CUR, or SEEK_END.
off_t l_start
This specifies the offset of the start of the region to which the lock
applies, and is given in bytes relative to the point specified by
l_whence member.
off_t l_len
This specifies the length of the region to be locked. A value of
0 is treated specially; it means the region extends to the end of
the file.
pid_t l_pid
This field is the process ID (see section 26.2 Process Creation Concepts) of the
process holding the lock. It is filled in by calling fcntl with
the F_GETLK command, but is ignored when making a lock.
Macro: int F_GETLK
This macro is used as the command argument to fcntl, to
specify that it should get information about a lock. This command
requires a third argument of type struct flock * to be passed
to fcntl, so that the form of the call is:
fcntl (filedes, F_GETLK, lockp)
If there is a lock already in place that would block the lock described
by the lockp argument, information about that lock overwrites
*lockp. Existing locks are not reported if they are
compatible with making a new lock as specified. Thus, you should
specify a lock type of F_WRLCK if you want to find out about both
read and write locks, or F_RDLCK if you want to find out about
write locks only.
There might be more than one lock affecting the region specified by the
lockp argument, but fcntl only returns information about
one of them. The l_whence member of the lockp structure is
set to SEEK_SET and the l_start and l_len fields
set to identify the locked region.
If no lock applies, the only change to the lockp structure is to
update the l_type to a value of F_UNLCK.
The normal return value from fcntl with this command is an
unspecified value other than -1, which is reserved to indicate an
error. The following errno error conditions are defined for
this command:
EBADF
The filedes argument is invalid.
EINVAL
Either the lockp argument doesn't specify valid lock information,
or the file associated with filedes doesn't support locks.
Macro: int F_SETLK
This macro is used as the command argument to fcntl, to
specify that it should set or clear a lock. This command requires a
third argument of type struct flock * to be passed to
fcntl, so that the form of the call is:
fcntl (filedes, F_SETLK, lockp)
If the process already has a lock on any part of the region, the old lock
on that part is replaced with the new lock. You can remove a lock
by specifying a lock type of F_UNLCK.
If the lock cannot be set, fcntl returns immediately with a value
of -1. This function does not block waiting for other processes
to release locks. If fcntl succeeds, it return a value other
than -1.
The following errno error conditions are defined for this
function:
EAGAIN
EACCES
The lock cannot be set because it is blocked by an existing lock on the
file. Some systems use EAGAIN in this case, and other systems
use EACCES; your program should treat them alike, after
F_SETLK. (The GNU system always uses EAGAIN.)
EBADF
Either: the filedes argument is invalid; you requested a read lock
but the filedes is not open for read access; or, you requested a
write lock but the filedes is not open for write access.
EINVAL
Either the lockp argument doesn't specify valid lock information,
or the file associated with filedes doesn't support locks.
ENOLCK
The system has run out of file lock resources; there are already too
many file locks in place.
Well-designed file systems never report this error, because they have no
limitation on the number of locks. However, you must still take account
of the possibility of this error, as it could result from network access
to a file system on another machine.
Macro: int F_SETLKW
This macro is used as the command argument to fcntl, to
specify that it should set or clear a lock. It is just like the
F_SETLK command, but causes the process to block (or wait)
until the request can be specified.
This command requires a third argument of type struct flock *, as
for the F_SETLK command.
The fcntl return values and errors are the same as for the
F_SETLK command, but these additional errno error conditions
are defined for this command:
The specified region is being locked by another process. But that
process is waiting to lock a region which the current process has
locked, so waiting for the lock would result in deadlock. The system
does not guarantee that it will detect all such conditions, but it lets
you know if it notices one.
The following macros are defined for use as values for the l_type
member of the flock structure. The values are integer constants.
F_RDLCK
This macro is used to specify a read (or shared) lock.
F_WRLCK
This macro is used to specify a write (or exclusive) lock.
F_UNLCK
This macro is used to specify that the region is unlocked.
As an example of a situation where file locking is useful, consider a
program that can be run simultaneously by several different users, that
logs status information to a common file. One example of such a program
might be a game that uses a file to keep track of high scores. Another
example might be a program that records usage or accounting information
for billing purposes.
Having multiple copies of the program simultaneously writing to the
file could cause the contents of the file to become mixed up. But
you can prevent this kind of problem by setting a write lock on the
file before actually writing to the file.
If the program also needs to read the file and wants to make sure that
the contents of the file are in a consistent state, then it can also use
a read lock. While the read lock is set, no other process can lock
that part of the file for writing.
Remember that file locks are only a voluntary protocol for
controlling access to a file. There is still potential for access to
the file by programs that don't use the lock protocol.
If you set the O_ASYNC status flag on a file descriptor
(see section 13.14 File Status Flags), a SIGIO signal is sent whenever
input or output becomes possible on that file descriptor. The process
or process group to receive the signal can be selected by using the
F_SETOWN command to the fcntl function. If the file
descriptor is a socket, this also selects the recipient of SIGURG
signals that are delivered when out-of-band data arrives on that socket;
see 16.9.8 Out-of-Band Data. (SIGURG is sent in any situation
where select would report the socket as having an "exceptional
condition". See section 13.8 Waiting for Input or Output.)
If the file descriptor corresponds to a terminal device, then SIGIO
signals are sent to the foreground process group of the terminal.
See section 27. Job Control.
The symbols in this section are defined in the header file
`fcntl.h'.
Macro: int F_GETOWN
This macro is used as the command argument to fcntl, to
specify that it should get information about the process or process
group to which SIGIO signals are sent. (For a terminal, this is
actually the foreground process group ID, which you can get using
tcgetpgrp; see 27.7.3 Functions for Controlling Terminal Access.)
The return value is interpreted as a process ID; if negative, its
absolute value is the process group ID.
The following errno error condition is defined for this command:
EBADF
The filedes argument is invalid.
Macro: int F_SETOWN
This macro is used as the command argument to fcntl, to
specify that it should set the process or process group to which
SIGIO signals are sent. This command requires a third argument
of type pid_t to be passed to fcntl, so that the form of
the call is:
fcntl (filedes, F_SETOWN, pid)
The pid argument should be a process ID. You can also pass a
negative number whose absolute value is a process group ID.
The return value from fcntl with this command is -1
in case of error and some other value if successful. The following
errno error conditions are defined for this command:
EBADF
The filedes argument is invalid.
ESRCH
There is no process or process group corresponding to pid.
The GNU system can handle most input/output operations on many different
devices and objects in terms of a few file primitives - read,
write and lseek. However, most devices also have a few
peculiar operations which do not fit into this model. Such as:
Changing the character font used on a terminal.
Telling a magnetic tape system to rewind or fast forward. (Since they
cannot move in byte increments, lseek is inapplicable).
Ejecting a disk from a drive.
Playing an audio track from a CD-ROM drive.
Maintaining routing tables for a network.
Although some such objects such as sockets and terminals
(2) have special functions of their own, it would
not be practical to create functions for all these cases.
Instead these minor operations, known as IOCTLs, are assigned code
numbers and multiplexed through the ioctl function, defined in
sys/ioctl.h. The code numbers themselves are defined in many
different headers.
Function: int ioctl(int filedes, int command, ...)
The ioctl function performs the generic I/O operation
command on filedes.
A third argument is usually present, either a single number or a pointer
to a structure. The meaning of this argument, the returned value, and
any error codes depends upon the command used. Often -1 is
returned for a failure.
On some systems, IOCTLs used by different devices share the same numbers.
Thus, although use of an inappropriate IOCTL usually only produces
an error, you should not attempt to use device-specific IOCTLs on an
unknown device.
Most IOCTLs are OS-specific and/or only used in special system utilities,
and are thus beyond the scope of this document. For an example of the use
of an IOCTL, see 16.9.8 Out-of-Band Data.