the lock is released. This strategy first originated in System V, and can be seen today in the Solaris, HP-UX, and Linux operating systems. It is not part of POSIX, however, and BSD-derived operating systems such as FreeBSD, OpenBSD, NetBSD, and Apple's macOS do not support it. Linux also supports mandatory locking through the special -o mand parameter for file system mounting (), but this is rarely used. Some Unix-like operating systems prevent attempts to open the executable file of a running program for writing; this is a third form of locking, separate from those provided by fcntl and flock. Problems More than one process can hold an exclusive flock on a given file if the exclusive lock was duplicated across a later fork. This simplifies coding for network servers and helps prevent race conditions, but can be confusing to the unaware. Mandatory locks have no effect on the unlink system call. Consequently, certain programs may, effectively, circumvent mandatory locking. Stevens & Rago (2005) observed that the ed editor indeed did that. Whether and how flock locks work on network filesystems, such as NFS, is implementation dependent. On BSD systems, flock calls on a file descriptor open to a file on an NFS-mounted partition are successful no-ops. On Linux prior to 2.6.12, flock calls on NFS files would act only locally. Kernel 2.6.12 and above implement flock calls on NFS files using POSIX byte-range locks. These locks will be visible to other NFS clients that implement fcntl-style POSIX locks, but invisible to those that do not. Lock upgrades and downgrades release the old lock before applying the new lock. If an application downgrades an exclusive lock to a shared lock while another application is blocked waiting for an exclusive lock, the latter application may get the exclusive lock and lock the first application out. This means that lock downgrades can block, which may be counter-intuitive. All fcntl locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process, even if a lock was never requested for that file descriptor. Also, fcntl locks are not inherited by a child process. The fcntl close semantics are particularly troublesome for applications that call subroutine libraries that may access files. Neither of these "bugs" occurs using real flock-style locks. Preservation of the lock status on open file descriptors passed to another process