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 section 7 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:
fileno to get the descriptor
corresponding to a stream.)
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'.
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 8.10 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 6.2.3 File Name Errors), the following errno error conditions are defined
for this function:
EACCES
EEXIST
O_CREAT and O_EXCL are set, and the named file already
exists.
EINTR
open operation was interrupted by a signal.
See section 21.5 Primitives Interrupted by Signals.
EISDIR
EMFILE
RLIMIT_NOFILE resource limit; see section 17.6 Limiting Resource Usage.
ENFILE
ENOENT
O_CREAT is not specified.
ENOSPC
ENXIO
O_NONBLOCK and O_WRONLY are both set in the flags
argument, the file named by filename is a FIFO (see section 10 Pipes and FIFOs), and no process has the file open for reading.
EROFS
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.
The open function is the underlying primitive for the fopen
and freopen functions, that create streams.
creat (filename, mode)
is equivalent to:
open (filename, O_WRONLY | O_CREAT | O_TRUNC, mode)
close closes the file descriptor filedes.
Closing a file has the following consequences:
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
EINTR
close call was interrupted by a signal.
See section 21.5 Primitives Interrupted by Signals.
Here is an example of how to handle EINTR properly:
TEMP_FAILURE_RETRY (close (desc));
ENOSPC
EIO
EDQUOT
write can sometimes
not be detected until close. See section 8.2 Input and Output Primitives, for details
on their meaning.
To close a stream, call fclose (see section 7.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'.
size_t,
but must be a signed type.
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 there is no terminating
null character 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
read waits for
some input. But if the O_NONBLOCK flag is set for the file
(see section 8.10 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
EINTR
read was interrupted by a signal while it was waiting for input.
See section 21.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
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
signal is being blocked or ignored, or because the process group is
orphaned. See section 24 Job Control, for more information about job control,
and section 21 Signal Handling, for information about signals.
The read function is the underlying primitive for all of the
functions that read from streams, such as fgetc.
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.)
You can use the O_FSYNC open mode to make write always
store the data to disk before returning; see section 8.10.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
write blocks until the write operation is complete.
But if the O_NONBLOCK flag is set for the file (see section 8.7 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
EFBIG
EINTR
write operation was interrupted by a signal while it was
blocked waiting for completion. A signal will not necessary cause
write to return EINTR; it may instead result in a
successful write which writes fewer bytes than requested.
See section 21.5 Primitives Interrupted by Signals.
EIO
ENOSPC
EPIPE
SIGPIPE
signal is also sent to the process; see section 21 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 21.5 Primitives Interrupted by Signals. The easy way to do this is with the
macro TEMP_FAILURE_RETRY, as follows:
nbytes = TEMP_FAILURE_RETRY (write (desc, buffer, count));
The write function is the underlying primitive for all of the
functions that write to streams, such as fputc.
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 7.15 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).
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 must be
one of the symbolic constants SEEK_SET, SEEK_CUR, or
SEEK_END.
SEEK_SET
SEEK_CUR
SEEK_END
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 8.10.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 so; 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
EINVAL
ESPIPE
ESPIPE if the object is not seekable.)
lseek function is the underlying primitive for the
fseek, ftell and rewind functions, which operate on
streams instead of file descriptors.
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,
{
int d1, d2, d3;
char buf1[4], buf2[4];
d1 = open ("foo", O_RDONLY);
d2 = dup (d1);
d3 = dup (d2);
lseek (d3, 1024, SEEK_SET);
read (d1, buf1, 4);
read (d2, buf2, 4);
}
will read four characters starting with the 1024'th character of
`foo', and then four more characters starting with the 1028'th
character.
fpos_t or long int.
L_SET
SEEK_SET.
L_INCR
SEEK_CUR.
L_XTND
SEEK_END.
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'.
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 7.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 affect 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 section 10.1 Creating a Pipe.
fileno returns -1.
There are also symbolic constants defined in `unistd.h' for the
file descriptors belonging to the standard streams stdin,
stdout, and stderr; see section 7.2 Standard Streams.
STDIN_FILENO
0, which is the file descriptor for
standard input.
STDOUT_FILENO
1, which is the file descriptor for
standard output.
STDERR_FILENO
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 8.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:
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 section 8.5.1 Linked Channels.
On the GNU system, you can clean up any stream with fclean:
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 12.4 Terminal Modes.
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 11.8.2 Listening for Connections), we say that
"input" is available when there are pending connections that could be
accepted (see section 11.8.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.
fd_set data type represents file descriptor sets for the
select function. It is actually a bit array.
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.
Next, here is the description of the select function itself.
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 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 11.8.3 Accepting Connections. A client socket is ready for writing when
its connection is fully established; see section 11.8.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 11 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 section 17.2.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 section 21.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
EINTR
EINVAL
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;
}
There is another example showing the use of select to multiplex
input from multiple sockets in section 11.8.7 Byte Stream Connection Server Example.
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 section 8.1 Opening and Closing Files.
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
F_GETFD
F_SETFD
F_GETFL
F_SETFL
F_GETLK
F_SETLK
F_SETLKW
F_SETLK, but wait for completion. See section 8.11 File Locks.
F_GETOWN
SIGIO signals.
See section 8.12 Interrupt-Driven Input.
F_SETOWN
SIGIO signals.
See section 8.12 Interrupt-Driven Input.
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 8.10 File Status Flags), but each has its own set of file descriptor flags (see section 8.9 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'.
fcntl (old, F_DUPFD, 0).
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.
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
EINVAL
EMFILE
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 23.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:
pid = fork ();
if (pid == 0)
{
char *filename;
char *program;
int file;
...
file = TEMP_FAILURE_RETRY (open (filename, O_RDONLY));
dup2 (file, STDIN_FILENO);
TEMP_FAILURE_RETRY (close (file));
execv (program, NULL);
}
There is also a more detailed example showing how to implement redirection in the context of a pipeline of processes in section 24.6.3 Launching Jobs.
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 23.5 Executing a File).
The symbols in this section are defined in the header file `fcntl.h'.
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
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.
exec function is invoked; see section 23.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 theFD_CLOEXECflag of desc if value is nonzero, or clear the flag if value is 0. Return 0 on success, or -1 on error witherrnoset. */ 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 section 8.9 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 8.1 Opening and Closing Files.
File status flags fall into three categories, which are described in the following sections.
open and are
returned by fcntl, but cannot be changed.
open will do.
These flags are not preserved after the open call.
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'.
open.
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.
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.
O_RDWR; only defined on GNU.
O_WRONLY; 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.
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 8.1 Opening and Closing Files, for how to call
open.
There are two sorts of options specified by open-time flags.
open looks up the
file name to locate the file, and whether the file can be created.
open will
perform on the file once it is open.
Here are the file name translation flags.
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.
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 8.10.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.
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.
fstat on the new file descriptor will
return the information returned by lstat on the link's name.)
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.
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.
flock.
See section 8.11 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.
flock.
See section 8.11 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.
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.
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 8.10.2 Open-time Flags.
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.
SIGIO
signals will be generated when input is available. See section 8.12 Interrupt-Driven Input.
Asynchronous input mode is a BSD feature.
write call will make sure the data is reliably stored on disk before
returning.
Synchronous writing is a BSD feature.
O_FSYNC. They have the same value.
read will not update the access time of the
file. See section 9.8.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.
This is a GNU extension.
The fcntl function can fetch or change file status flags.
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
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 theO_NONBLOCKflag of desc if value is nonzero, or clear the flag if value is 0. Return 0 on success, or -1 on error witherrnoset. */ 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 23.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'.
fcntl function to describe a file
lock. It has these members:
short int l_type
F_RDLCK, F_WRLCK, or
F_UNLCK.
short int l_whence
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
l_whence member.
off_t l_len
0 is treated specially; it means the region extends to the end of
the file.
pid_t l_pid
fcntl with
the F_GETLK command, but is ignored when making a lock.
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
EINVAL
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
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
EINVAL
ENOLCK
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:
EINTR
EDEADLK
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
F_WRLCK
F_UNLCK
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 8.10 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 section 11.8.8 Out-of-Band Data. (SIGURG is sent in any situation
where select would report the socket as having an "exceptional
condition". See section 8.6 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 24 Job Control.
The symbols in this section are defined in the header file `fcntl.h'.
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 section 24.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
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
ESRCH
Go to the first, previous, next, last section, table of contents.