]> git.ipfire.org Git - thirdparty/man-pages.git/blame - man2/flock.2
Fix inconsistencies in .TH line
[thirdparty/man-pages.git] / man2 / flock.2
CommitLineData
fea681da
MK
1.\" Hey Emacs! This file is -*- nroff -*- source.
2.\"
c13182ef 3.\" Copyright 1993 Rickard E. Faith (faith@cs.unc.edu) and
6883b3e7 4.\" and Copyright 2002 Michael Kerrisk
fea681da
MK
5.\"
6.\" Permission is granted to make and distribute verbatim copies of this
7.\" manual provided the copyright notice and this permission notice are
8.\" preserved on all copies.
9.\"
10.\" Permission is granted to copy and distribute modified versions of this
11.\" manual under the conditions for verbatim copying, provided that the
12.\" entire resulting derived work is distributed under the terms of a
13.\" permission notice identical to this one.
c13182ef 14.\"
fea681da
MK
15.\" Since the Linux kernel and libraries are constantly changing, this
16.\" manual page may be incorrect or out-of-date. The author(s) assume no
17.\" responsibility for errors or omissions, or for damages resulting from
18.\" the use of the information contained herein. The author(s) may not
19.\" have taken the same level of care in the production of this manual,
20.\" which is licensed free of charge, as they might when working
21.\" professionally.
c13182ef 22.\"
fea681da
MK
23.\" Formatted or processed versions of this manual, if unaccompanied by
24.\" the source, must acknowledge the copyright and authors of this work.
25.\"
26.\" Modified Fri Jan 31 16:26:07 1997 by Eric S. Raymond <esr@thyrsus.com>
27.\" Modified Fri Dec 11 17:57:27 1998 by Jamie Lokier <jamie@imbolc.ucc.ie>
305a0578 28.\" Modified 24 Apr 2002 by Michael Kerrisk <mtk-manpages@gmx.net>
fea681da 29.\" Substantial rewrites and additions
6a916f1c 30.\" 2005-05-10 mtk, noted that lock conversions are not atomic.
fea681da 31.\"
05eabe65 32.TH FLOCK 2 2002-04-24 "Linux" "Linux Programmer's Manual"
fea681da
MK
33.SH NAME
34flock \- apply or remove an advisory lock on an open file
35.SH SYNOPSIS
36.B #include <sys/file.h>
37.sp
964d4d9c 38.BI "int flock(int " fd ", int " operation );
fea681da
MK
39.SH DESCRIPTION
40Apply or remove an advisory lock on the open file specified by
41.IR fd .
42The parameter
43.I operation
44is one of the following:
45.RS
fea681da
MK
46.TP 1.0i
47.B LOCK_SH
48Place a shared lock.
49More than one process may hold a shared lock for a given file
50at a given time.
51.TP
52.B LOCK_EX
53Place an exclusive lock.
54Only one process may hold an exclusive lock for a given
55file at a given time.
56.TP
57.B LOCK_UN
58Remove an existing lock held by this process.
59.sp
60.RE
fea681da
MK
61A call to
62.BR flock ()
63may block if an incompatible lock is held by another process.
64To make a non-blocking request, include
65.B LOCK_NB
66(by
67.IR OR ing)
68with any of the above operations.
69
70A single file may not simultaneously have both shared and exclusive locks.
71
72Locks created by
73.BR flock ()
d04e1109 74are associated with an open file table entry.
fea681da 75This means that duplicate file descriptors (created by, for example,
c13182ef 76.BR fork (2)
35e21ba7
MK
77or
78.BR dup (2))
fea681da
MK
79refer to the same lock, and this lock may be modified
80or released using any of these descriptors.
81Furthermore, the lock is released either by an explicit
82.B LOCK_UN
83operation on any of these duplicate descriptors, or when all
84such descriptors have been closed.
85
d04e1109
MK
86If a process uses
87.BR open (2)
88(or similar) to obtain more than one descriptor for the same file,
89these descriptors are treated independently by
90.BR flock ().
91An attempt to lock the file using one of these file descriptors
92may be denied by a lock that the calling process has
93already placed via another descriptor.
94
fea681da
MK
95A process may only hold one type of lock (shared or exclusive)
96on a file.
97Subsequent
98.BR flock ()
99calls on an already locked file will convert an existing lock to the new
100lock mode.
101
102Locks created by
103.BR flock ()
104are preserved across an
105.BR execve (2).
106
107A shared or exclusive lock can be placed on a file regardless of the
108mode in which the file was opened.
109.SH "RETURN VALUE"
c13182ef
MK
110On success, zero is returned.
111On error, \-1 is returned, and
fea681da
MK
112.I errno
113is set appropriately.
114.SH ERRORS
115.TP
116.B EBADF
117.I fd
118is not a not an open file descriptor.
119.TP
120.B EINTR
121While waiting to acquire a lock, the call was interrupted by
122delivery of a signal caught by a handler.
123.TP
124.B EINVAL
125.I operation
126is invalid.
127.TP
128.B ENOLCK
129The kernel ran out of memory for allocating lock records.
130.TP
131.B EWOULDBLOCK
132The file is locked and the
133.B LOCK_NB
134flag was selected.
135.SH "CONFORMING TO"
1364.4BSD (the
137.BR flock (2)
138call first appeared in 4.2BSD).
139A version of
140.BR flock (2),
141possibly implemented in terms of
142.BR fcntl (2),
d24e2319 143appears on most Unix systems.
fea681da
MK
144.SH NOTES
145.BR flock (2)
c13182ef
MK
146does not lock files over NFS.
147Use
fea681da
MK
148.BR fcntl (2)
149instead: that does work over NFS, given a sufficiently recent version of
150Linux and a server which supports locking.
151.PP
152Since kernel 2.0,
153.BR flock (2)
154is implemented as a system call in its own right rather
155than being emulated in the GNU C library as a call to
156.BR fcntl (2).
157This yields true BSD semantics:
158there is no interaction between the types of lock
159placed by
160.BR flock (2)
161and
162.BR fcntl (2),
163and
164.BR flock (2)
165does not detect deadlock.
166.PP
167.BR flock (2)
168places advisory locks only; given suitable permissions on a file,
169a process is free to ignore the use of
170.BR flock (2)
171and perform I/O on the file.
172.PP
173.BR flock (2)
174and
175.BR fcntl (2)
176locks have different semantics with respect to forked processes and
177.BR dup (2).
d04e1109
MK
178On systems that implement
179.BR flock ()
180using
0bfa087b 181.BR fcntl (2),
d04e1109
MK
182the semantics of
183.BR flock ()
184will be different from those described in this manual page.
6a916f1c
MK
185.PP
186Converting a lock
187(shared to exclusive, or vice versa) is not guaranteed to be atomic:
188the existing lock is first removed, and then a new lock is established.
189Between these two steps,
190a pending lock request by another process may be granted,
c13182ef 191with the result that the conversion either blocks, or fails if
6a916f1c
MK
192.B LOCK_NB
193was specified.
194(This is the original BSD behaviour,
195and occurs on many other implementations.)
196.\" Kernel 2.5.21 changed things a little: during lock conversion
197.\" it is now the highest priority process that will get the lock -- mtk
c10859eb 198.SH "SEE ALSO"
fea681da
MK
199.BR close (2),
200.BR dup (2),
201.BR execve (2),
202.BR fcntl (2),
203.BR fork (2),
204.BR open (2),
205.BR lockf (3)
206
207There are also
208.I locks.txt
209and
210.I mandatory.txt
211in
212.IR /usr/src/linux/Documentation .