---

   fcntl    ( 2 )

---

Примечание (Note)

The errors returned by dup2(2) are different from those returned
       by F_DUPFD.

   File locking
       The original Linux fcntl() system call was not designed to handle
       large file offsets (in the flock structure).  Consequently, an
       fcntl64() system call was added in Linux 2.4.  The newer system
       call employs a different structure for file locking, flock64, and
       corresponding commands, F_GETLK64, F_SETLK64, and F_SETLKW64.
       However, these details can be ignored by applications using
       glibc, whose fcntl() wrapper function transparently employs the
       more recent system call where it is available.

   Record locks
       Since kernel 2.0, there is no interaction between the types of
       lock placed by flock(2) and fcntl().

       Several systems have more fields in struct flock such as, for
       example, l_sysid (to identify the machine where the lock is
       held).  Clearly, l_pid alone is not going to be very useful if
       the process holding the lock may live on a different machine; on
       Linux, while present on some architectures (such as MIPS32), this
       field is not used.

       The original Linux fcntl() system call was not designed to handle
       large file offsets (in the flock structure).  Consequently, an
       fcntl64() system call was added in Linux 2.4.  The newer system
       call employs a different structure for file locking, flock64, and
       corresponding commands, F_GETLK64, F_SETLK64, and F_SETLKW64.
       However, these details can be ignored by applications using
       glibc, whose fcntl() wrapper function transparently employs the
       more recent system call where it is available.

   Record locking and NFS
       Before Linux 3.12, if an NFSv4 client loses contact with the
       server for a period of time (defined as more than 90 seconds with
       no communication), it might lose and regain a lock without ever
       being aware of the fact.  (The period of time after which contact
       is assumed lost is known as the NFSv4 leasetime.  On a Linux NFS
       server, this can be determined by looking at
       /proc/fs/nfsd/nfsv4leasetime, which expresses the period in
       seconds.  The default value for this file is 90.)  This scenario
       potentially risks data corruption, since another process might
       acquire a lock in the intervening period and perform file I/O.

       Since Linux 3.12, if an NFSv4 client loses contact with the
       server, any I/O to the file by a process which "thinks" it holds
       a lock will fail until that process closes and reopens the file.
       A kernel parameter, nfs.recover_lost_locks, can be set to 1 to
       obtain the pre-3.12 behavior, whereby the client will attempt to
       recover lost locks when contact is reestablished with the server.
       Because of the attendant risk of data corruption, this parameter
       defaults to 0 (disabled).