]> git.ipfire.org Git - thirdparty/man-pages.git/blob - man3p/fcntl.3p
Import of man-pages 1.70
[thirdparty/man-pages.git] / man3p / fcntl.3p
1 .\" Copyright (c) 2001-2003 The Open Group, All Rights Reserved
2 .TH "FCNTL" P 2003 "IEEE/The Open Group" "POSIX Programmer's Manual"
3 .\" fcntl
4 .SH NAME
5 fcntl \- file control
6 .SH SYNOPSIS
7 .LP
8 \fB#include <unistd.h> \fP
9 \fB
10 .br
11 #include <fcntl.h>
12 .br
13 .sp
14 int fcntl(int\fP \fIfildes\fP\fB, int\fP \fIcmd\fP\fB, ...);
15 .br
16 \fP
17 .SH DESCRIPTION
18 .LP
19 The \fIfcntl\fP() function shall perform the operations described
20 below on open files. The \fIfildes\fP argument is a file
21 descriptor.
22 .LP
23 The available values for \fIcmd\fP are defined in \fI<fcntl.h>\fP
24 and are as
25 follows:
26 .TP 7
27 F_DUPFD
28 Return a new file descriptor which shall be the lowest numbered available
29 (that is, not already open) file descriptor greater
30 than or equal to the third argument, \fIarg\fP, taken as an integer
31 of type \fBint\fP. The new file descriptor shall refer to the
32 same open file description as the original file descriptor, and shall
33 share any locks. The FD_CLOEXEC flag associated with the new
34 file descriptor shall be cleared to keep the file open across calls
35 to one of the \fIexec\fP
36 functions.
37 .TP 7
38 F_GETFD
39 Get the file descriptor flags defined in \fI<fcntl.h>\fP that are
40 associated with
41 the file descriptor \fIfildes\fP. File descriptor flags are associated
42 with a single file descriptor and do not affect other file
43 descriptors that refer to the same file.
44 .TP 7
45 F_SETFD
46 Set the file descriptor flags defined in \fI<fcntl.h>\fP, that are
47 associated
48 with \fIfildes\fP, to the third argument, \fIarg\fP, taken as type
49 \fBint\fP. If the FD_CLOEXEC flag in the third argument is 0,
50 the file shall remain open across the \fIexec\fP functions; otherwise,
51 the file shall be
52 closed upon successful execution of one of the \fIexec\fP functions.
53 .TP 7
54 F_GETFL
55 Get the file status flags and file access modes, defined in \fI<fcntl.h>\fP,
56 for
57 the file description associated with \fIfildes\fP. The file access
58 modes can be extracted from the return value using the mask
59 O_ACCMODE, which is defined in \fI<fcntl.h>\fP. File status flags
60 and file access
61 modes are associated with the file description and do not affect other
62 file descriptors that refer to the same file with different
63 open file descriptions.
64 .TP 7
65 F_SETFL
66 Set the file status flags, defined in \fI<fcntl.h>\fP, for the file
67 description
68 associated with \fIfildes\fP from the corresponding bits in the third
69 argument, \fIarg\fP, taken as type \fBint\fP. Bits
70 corresponding to the file access mode and the file creation flags,
71 as defined in \fI<fcntl.h>\fP, that are set in \fIarg\fP shall be
72 ignored. If any bits in \fIarg\fP other
73 than those mentioned here are changed by the application, the result
74 is unspecified.
75 .TP 7
76 F_GETOWN
77 If \fIfildes\fP refers to a socket, get the process or process group
78 ID specified to receive SIGURG signals when out-of-band
79 data is available. Positive values indicate a process ID; negative
80 values, other than -1, indicate a process group ID. If
81 \fIfildes\fP does not refer to a socket, the results are unspecified.
82 .TP 7
83 F_SETOWN
84 If \fIfildes\fP refers to a socket, set the process or process group
85 ID specified to receive SIGURG signals when out-of-band
86 data is available, using the value of the third argument, \fIarg\fP,
87 taken as type \fBint\fP. Positive values indicate a process
88 ID; negative values, other than -1, indicate a process group ID. If
89 \fIfildes\fP does not refer to a socket, the results are
90 unspecified.
91 .sp
92 .LP
93 The following values for \fIcmd\fP are available for advisory record
94 locking. Record locking shall be supported for regular
95 files, and may be supported for other files.
96 .TP 7
97 F_GETLK
98 Get the first lock which blocks the lock description pointed to by
99 the third argument, \fIarg\fP, taken as a pointer to type
100 \fBstruct flock\fP, defined in \fI<fcntl.h>\fP. The information retrieved
101 shall
102 overwrite the information passed to \fIfcntl\fP() in the structure
103 \fBflock\fP. If no lock is found that would prevent this lock
104 from being created, then the structure shall be left unchanged except
105 for the lock type which shall be set to F_UNLCK.
106 .TP 7
107 F_SETLK
108 Set or clear a file segment lock according to the lock description
109 pointed to by the third argument, \fIarg\fP, taken as a
110 pointer to type \fBstruct flock\fP, defined in \fI<fcntl.h>\fP. F_SETLK
111 can
112 establish shared (or read) locks (F_RDLCK) or exclusive (or write)
113 locks (F_WRLCK), as well as to remove either type of lock
114 (F_UNLCK). F_RDLCK, F_WRLCK, and F_UNLCK are defined in \fI<fcntl.h>\fP.
115 If a shared
116 or exclusive lock cannot be set, \fIfcntl\fP() shall return immediately
117 with a return value of -1.
118 .TP 7
119 F_SETLKW
120 This command shall be equivalent to F_SETLK except that if a shared
121 or exclusive lock is blocked by other locks, the thread
122 shall wait until the request can be satisfied. If a signal that is
123 to be caught is received while \fIfcntl\fP() is waiting for a
124 region, \fIfcntl\fP() shall be interrupted. Upon return from the signal
125 handler, \fIfcntl\fP() shall return -1 with \fIerrno\fP
126 set to [EINTR], and the lock operation shall not be done.
127 .sp
128 .LP
129 Additional implementation-defined values for \fIcmd\fP may be defined
130 in \fI<fcntl.h>\fP. Their names shall start with F_.
131 .LP
132 When a shared lock is set on a segment of a file, other processes
133 shall be able to set shared locks on that segment or a portion
134 of it. A shared lock prevents any other process from setting an exclusive
135 lock on any portion of the protected area. A request for
136 a shared lock shall fail if the file descriptor was not opened with
137 read access.
138 .LP
139 An exclusive lock shall prevent any other process from setting a shared
140 lock or an exclusive lock on any portion of the
141 protected area. A request for an exclusive lock shall fail if the
142 file descriptor was not opened with write access.
143 .LP
144 The structure \fBflock\fP describes the type ( \fIl_type\fP), starting
145 offset ( \fIl_whence\fP), relative offset (
146 \fIl_start\fP), size ( \fIl_len\fP), and process ID ( \fIl_pid\fP)
147 of the segment of the file to be affected.
148 .LP
149 The value of \fIl_whence\fP is SEEK_SET, SEEK_CUR, or SEEK_END, to
150 indicate that the relative offset \fIl_start\fP bytes shall
151 be measured from the start of the file, current position, or end of
152 the file, respectively. The value of \fIl_len\fP is the number
153 of consecutive bytes to be locked. The value of \fIl_len\fP may be
154 negative (where the definition of \fBoff_t\fP permits negative
155 values of \fIl_len\fP). The \fIl_pid\fP field is only used with F_GETLK
156 to return the process ID of the process holding a
157 blocking lock. After a successful F_GETLK request, when a blocking
158 lock is found, the values returned in the \fBflock\fP structure
159 shall be as follows:
160 .TP 7
161 \fIl_type\fP
162 Type of blocking lock found.
163 .TP 7
164 \fIl_whence\fP
165 SEEK_SET.
166 .TP 7
167 \fIl_start\fP
168 Start of the blocking lock.
169 .TP 7
170 \fIl_len\fP
171 Length of the blocking lock.
172 .TP 7
173 \fIl_pid\fP
174 Process ID of the process that holds the blocking lock.
175 .sp
176 .LP
177 If the command is F_SETLKW and the process must wait for another process
178 to release a lock, then the range of bytes to be locked
179 shall be determined before the \fIfcntl\fP() function blocks. If the
180 file size or file descriptor seek offset change while
181 \fIfcntl\fP() is blocked, this shall not affect the range of bytes
182 locked.
183 .LP
184 If \fIl_len\fP is positive, the area affected shall start at \fIl_start\fP
185 and end at \fIl_start\fP+ \fIl_len\fP-1. If
186 \fIl_len\fP is negative, the area affected shall start at \fIl_start\fP+
187 \fIl_len\fP and end at \fIl_start\fP-1. Locks may
188 start and extend beyond the current end of a file, but shall not extend
189 before the beginning of the file. A lock shall be set to
190 extend to the largest possible value of the file offset for that file
191 by setting \fIl_len\fP to 0. If such a lock also has
192 \fIl_start\fP set to 0 and \fIl_whence\fP is set to SEEK_SET, the
193 whole file shall be locked.
194 .LP
195 There shall be at most one type of lock set for each byte in the file.
196 Before a successful return from an F_SETLK or an F_SETLKW
197 request when the calling process has previously existing locks on
198 bytes in the region specified by the request, the previous lock
199 type for each byte in the specified region shall be replaced by the
200 new lock type. As specified above under the descriptions of
201 shared locks and exclusive locks, an F_SETLK or an F_SETLKW request
202 (respectively) shall fail or block when another process has
203 existing locks on bytes in the specified region and the type of any
204 of those locks conflicts with the type specified in the
205 request.
206 .LP
207 All locks associated with a file for a given process shall be removed
208 when a file descriptor for that file is closed by that
209 process or the process holding that file descriptor terminates. Locks
210 are not inherited by a child process.
211 .LP
212 A potential for deadlock occurs if a process controlling a locked
213 region is put to sleep by attempting to lock another process'
214 locked region. If the system detects that sleeping until a locked
215 region is unlocked would cause a deadlock, \fIfcntl\fP() shall
216 fail with an [EDEADLK] error.
217 .LP
218 An unlock (F_UNLCK) request in which \fIl_len\fP is non-zero and the
219 offset of the last byte of the requested segment is the
220 maximum value for an object of type \fBoff_t\fP, when the process
221 has an existing lock in which \fIl_len\fP is 0 and which
222 includes the last byte of the requested segment, shall be treated
223 as a request to unlock from the start of the requested segment
224 with an \fIl_len\fP equal to 0. Otherwise, an unlock (F_UNLCK) request
225 shall attempt to unlock only the requested segment.
226 .LP
227 When the file descriptor \fIfildes\fP refers to a shared memory object,
228 the behavior of \fIfcntl\fP() shall be the same as for a
229 regular file except the effect of the following values for the argument
230 \fIcmd\fP shall be unspecified: F_SETFL, F_GETLK, F_SETLK,
231 and F_SETLKW.
232 .LP
233 If \fIfildes\fP refers to a typed memory object, the result of the
234 \fIfcntl\fP() function is unspecified.
235 .SH RETURN VALUE
236 .LP
237 Upon successful completion, the value returned shall depend on \fIcmd\fP
238 as follows:
239 .TP 7
240 F_DUPFD
241 A new file descriptor.
242 .TP 7
243 F_GETFD
244 Value of flags defined in \fI<fcntl.h>\fP. The return value shall
245 not be
246 negative.
247 .TP 7
248 F_SETFD
249 Value other than -1.
250 .TP 7
251 F_GETFL
252 Value of file status flags and access modes. The return value is not
253 negative.
254 .TP 7
255 F_SETFL
256 Value other than -1.
257 .TP 7
258 F_GETLK
259 Value other than -1.
260 .TP 7
261 F_SETLK
262 Value other than -1.
263 .TP 7
264 F_SETLKW
265 Value other than -1.
266 .TP 7
267 F_GETOWN
268 Value of the socket owner process or process group; this will not
269 be -1.
270 .TP 7
271 F_SETOWN
272 Value other than -1.
273 .sp
274 .LP
275 Otherwise, -1 shall be returned and \fIerrno\fP set to indicate the
276 error.
277 .SH ERRORS
278 .LP
279 The \fIfcntl\fP() function shall fail if:
280 .TP 7
281 .B EACCES \fRor\fP EAGAIN
282 .sp
283 The \fIcmd\fP argument is F_SETLK; the type of lock ( \fIl_type\fP)
284 is a shared (F_RDLCK) or exclusive (F_WRLCK) lock and the
285 segment of a file to be locked is already exclusive-locked by another
286 process, or the type is an exclusive lock and some portion of
287 the segment of a file to be locked is already shared-locked or exclusive-locked
288 by another process.
289 .TP 7
290 .B EBADF
291 The \fIfildes\fP argument is not a valid open file descriptor, or
292 the argument \fIcmd\fP is F_SETLK or F_SETLKW, the type of
293 lock, \fIl_type\fP, is a shared lock (F_RDLCK), and \fIfildes\fP is
294 not a valid file descriptor open for reading, or the type of
295 lock, \fIl_type\fP, is an exclusive lock (F_WRLCK), and \fIfildes\fP
296 is not a valid file descriptor open for writing.
297 .TP 7
298 .B EINTR
299 The \fIcmd\fP argument is F_SETLKW and the function was interrupted
300 by a signal.
301 .TP 7
302 .B EINVAL
303 The \fIcmd\fP argument is invalid, or the \fIcmd\fP argument is F_DUPFD
304 and \fIarg\fP is negative or greater than or equal
305 to {OPEN_MAX}, or the \fIcmd\fP argument is F_GETLK, F_SETLK, or F_SETLKW
306 and the data pointed to by \fIarg\fP is not valid, or
307 \fIfildes\fP refers to a file that does not support locking.
308 .TP 7
309 .B EMFILE
310 The argument \fIcmd\fP is F_DUPFD and {OPEN_MAX} file descriptors
311 are currently open in the calling process, or no file
312 descriptors greater than or equal to \fIarg\fP are available.
313 .TP 7
314 .B ENOLCK
315 The argument \fIcmd\fP is F_SETLK or F_SETLKW and satisfying the lock
316 or unlock request would result in the number of locked
317 regions in the system exceeding a system-imposed limit.
318 .TP 7
319 .B EOVERFLOW
320 One of the values to be returned cannot be represented correctly.
321 .TP 7
322 .B EOVERFLOW
323 The \fIcmd\fP argument is F_GETLK, F_SETLK, or F_SETLKW and the smallest
324 or, if \fIl_len\fP is non-zero, the largest offset
325 of any byte in the requested segment cannot be represented correctly
326 in an object of type \fBoff_t\fP.
327 .sp
328 .LP
329 The \fIfcntl\fP() function may fail if:
330 .TP 7
331 .B EDEADLK
332 The \fIcmd\fP argument is F_SETLKW, the lock is blocked by a lock
333 from another process, and putting the calling process to
334 sleep to wait for that lock to become free would cause a deadlock.
335 .sp
336 .LP
337 \fIThe following sections are informative.\fP
338 .SH EXAMPLES
339 .LP
340 None.
341 .SH APPLICATION USAGE
342 .LP
343 None.
344 .SH RATIONALE
345 .LP
346 The ellipsis in the SYNOPSIS is the syntax specified by the ISO\ C
347 standard for a variable number of arguments. It is used
348 because System V uses pointers for the implementation of file locking
349 functions.
350 .LP
351 The \fIarg\fP values to F_GETFD, F_SETFD, F_GETFL, and F_SETFL all
352 represent flag values to allow for future growth.
353 Applications using these functions should do a read-modify-write operation
354 on them, rather than assuming that only the values
355 defined by this volume of IEEE\ Std\ 1003.1-2001 are valid. It is
356 a common error to forget this, particularly in the case
357 of F_SETFD.
358 .LP
359 This volume of IEEE\ Std\ 1003.1-2001 permits concurrent read and
360 write access to file data using the \fIfcntl\fP()
361 function; this is a change from the 1984 /usr/group standard and early
362 proposals. Without concurrency controls, this feature may
363 not be fully utilized without occasional loss of data.
364 .LP
365 Data losses occur in several ways. One case occurs when several processes
366 try to update the same record, without sequencing
367 controls; several updates may occur in parallel and the last writer
368 "wins". Another case is a bit-tree or other internal
369 list-based database that is undergoing reorganization. Without exclusive
370 use to the tree segment by the updating process, other
371 reading processes chance getting lost in the database when the index
372 blocks are split, condensed, inserted, or deleted. While
373 \fIfcntl\fP() is useful for many applications, it is not intended
374 to be overly general and does not handle the bit-tree example
375 well.
376 .LP
377 This facility is only required for regular files because it is not
378 appropriate for many devices such as terminals and network
379 connections.
380 .LP
381 Since \fIfcntl\fP() works with "any file descriptor associated with
382 that file, however it is obtained", the file descriptor
383 may have been inherited through a \fIfork\fP() or \fIexec\fP operation
384 and thus may affect a file that another process also has open.
385 .LP
386 The use of the open file description to identify what to lock requires
387 extra calls and presents problems if several processes
388 are sharing an open file description, but there are too many implementations
389 of the existing mechanism for this volume of
390 IEEE\ Std\ 1003.1-2001 to use different specifications.
391 .LP
392 Another consequence of this model is that closing any file descriptor
393 for a given file (whether or not it is the same open file
394 description that created the lock) causes the locks on that file to
395 be relinquished for that process. Equivalently, any close for
396 any file/process pair relinquishes the locks owned on that file for
397 that process. But note that while an open file description may
398 be shared through \fIfork\fP(), locks are not inherited through \fIfork\fP().
399 Yet locks may be inherited through one of the \fIexec\fP functions.
400 .LP
401 The identification of a machine in a network environment is outside
402 the scope of this volume of IEEE\ Std\ 1003.1-2001.
403 Thus, an \fIl_sysid\fP member, such as found in System V, is not included
404 in the locking structure.
405 .LP
406 Changing of lock types can result in a previously locked region being
407 split into smaller regions.
408 .LP
409 Mandatory locking was a major feature of the 1984 /usr/group standard.
410 .LP
411 For advisory file record locking to be effective, all processes that
412 have access to a file must cooperate and use the advisory
413 mechanism before doing I/O on the file. Enforcement-mode record locking
414 is important when it cannot be assumed that all processes
415 are cooperating. For example, if one user uses an editor to update
416 a file at the same time that a second user executes another
417 process that updates the same file and if only one of the two processes
418 is using advisory locking, the processes are not
419 cooperating. Enforcement-mode record locking would protect against
420 accidental collisions.
421 .LP
422 Secondly, advisory record locking requires a process using locking
423 to bracket each I/O operation with lock (or test) and unlock
424 operations. With enforcement-mode file and record locking, a process
425 can lock the file once and unlock when all I/O operations have
426 been completed. Enforcement-mode record locking provides a base that
427 can be enhanced; for example, with sharable locks. That is,
428 the mechanism could be enhanced to allow a process to lock a file
429 so other processes could read it, but none of them could write
430 it.
431 .LP
432 Mandatory locks were omitted for several reasons:
433 .IP " 1." 4
434 Mandatory lock setting was done by multiplexing the set-group-ID bit
435 in most implementations; this was confusing, at best.
436 .LP
437 .IP " 2." 4
438 The relationship to file truncation as supported in 4.2 BSD was not
439 well specified.
440 .LP
441 .IP " 3." 4
442 Any publicly readable file could be locked by anyone. Many historical
443 implementations keep the password database in a publicly
444 readable file. A malicious user could thus prohibit logins. Another
445 possibility would be to hold open a long-distance telephone
446 line.
447 .LP
448 .IP " 4." 4
449 Some demand-paged historical implementations offer memory mapped files,
450 and enforcement cannot be done on that type of file.
451 .LP
452 .LP
453 Since sleeping on a region is interrupted with any signal, \fIalarm\fP()
454 may be used to
455 provide a timeout facility in applications requiring it. This is useful
456 in deadlock detection. Since implementation of full
457 deadlock detection is not always feasible, the [EDEADLK] error was
458 made optional.
459 .SH FUTURE DIRECTIONS
460 .LP
461 None.
462 .SH SEE ALSO
463 .LP
464 \fIalarm\fP() , \fIclose\fP() , \fIexec\fP() , \fIopen\fP() , \fIsigaction\fP()
465 , the Base Definitions volume of IEEE\ Std\ 1003.1-2001, \fI<fcntl.h>\fP,
466 \fI<signal.h>\fP, \fI<unistd.h>\fP
467 .SH COPYRIGHT
468 Portions of this text are reprinted and reproduced in electronic form
469 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
470 -- Portable Operating System Interface (POSIX), The Open Group Base
471 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
472 Electrical and Electronics Engineers, Inc and The Open Group. In the
473 event of any discrepancy between this version and the original IEEE and
474 The Open Group Standard, the original IEEE and The Open Group Standard
475 is the referee document. The original Standard can be obtained online at
476 http://www.opengroup.org/unix/online.html .