Artificial intelligent assistant

Duplication of a file descriptor associated with an fcntl lock? According to the man page of `dup2`, this syscall make a new copy of the old file descriptor. The two descriptors do not share (the close-on-exec flag). However in case the file descriptor we are trying to duplicate has an fcntl lock associated with it, does the new file descriptor get a new lock ?

Posix locks (F_SETLK etc) are associated with a process, so after a `dup2()` you still only have one lock on a file. You can list your locks with `lslocks`. If you close one of the 2 fds you will drop the lock. If you change the lock with one of the fds, the other will change too. After a `fork()` the child has no locks. See the `fcntl` man page for details. This Posix spec says `dup2()` will _share any locks_.

You can do simple tests in Python using `lockf()` for ease of use, as it is implemented via `fcntl()`, eg:


#!/usr/bin/python
import os, fcntl
pid = os.getpid()
fd = open("/tmp/try","rw")
fcntl.lockf(fd,fcntl.LOCK_SH,10)
fd2 = os.dup(fd.fileno())
os.system("lslocks -p %d" % pid) # one lock
fd.close()
os.system("lslocks -p %d" % pid) # no output

xcX3v84RxoQ-4GxG32940ukFUIEgYdPy 5ae7bf19d5bb817c7a36ca9041714dc6