3 ms·

Reading the Linux and BSD man pages for flock confuses me. https://man7.org/linux/man-pages/man2/flock.2.html https://man7.org/linux/man-pages/man2/flock.2.htm

Reading the Linux and BSD man pages for flock confuses me. https://man7.org/linux/man-pages/man2/flock.2.html https://man7.org/linux/man-pages/man2/flock.2.html says: “Locks created by flock() are associated with an open file description” On the other hand https://man.openbsd.org/flock.2 https://man.openbsd.org/flock.2 says: “Locks are on files, not file descriptors.” I guess the truth is in the middle. They’re associated with file descriptors, but cloning a file descriptor (e.g. through fork or dup) gives you true clones that both hold the lock. Or are the Linux and OpenBSD functions subtly different? The Linux man page also is confusing in that it says “Only one process may hold an exclusive lock for a given file at a given time” while, if I understand things correctly, also claiming that a forked process retains the locks of the parent process. So, what happens if that’s an exclusive lock? Does fork fail?

colanderman 4y ago
The statements are not contradictory, just confusingly worded. A lock is on a file, held by an open file description. Also note that, "open file description" != "file descriptor". An open file description exists only in the kernel, and is created on open(2). A file descriptor is the userland-visible handle to this open file description. dup(2) creates a new handle (file descriptor) pointing to this same open file description. Therefore, dup(2), fork(2), etc., do not violate the mutex property of the lock, since they are duplicating the file descriptors (handles), not the open file descriptions (which actually hold the locks). What's not clear from the man pages is what happens to a locked open file description which is passed to another process via a Unix domain socket. I suspect at that point, both "processes" "hold" the lock -- which in reality simply means they both have a file descriptor referring to the same single open file description which holds the lock, thus not violating the mutex property. Though this contradicts the extensive verbiage in flock(2) which refers to "processes" as being subject to the mutex property, I suspect that is a simplification, as later text in flock(2) indicates that open file descriptions are indeed the subject of the mutex property.
- Joker_vD 4y ago
  In the Windows land, those things are indeed called "file objects" and "file handles" respectively, which is a much less confusing terminology.
- Someone 4y ago
  Thanks! Completely overlooked that they talked about ‘description’, not ‘descriptor’ in several places. It would have helped me if they pointed out that difference in a clearer way. The Linux man page says ‘Locks created by flock() are associated with an open file description (see open(2))’, and that says: “The term open file description is the one used by POSIX to refer to the entries in the system-wide table of open files. In other contexts, this object is variously also called an "open file object", a "file handle", an "open file table entry", or—in kernel-developer parlance—a struct file.”
  - yrro 4y ago
    > Thanks! Completely overlooked that they talked about ‘description’, not ‘descriptor’ in several places. The classic "close reading" that man pages require...

colanderman 4y ago

The statements are not contradictory, just confusingly worded. A lock is on a file, held by an open file description. Also note that, "open file description" != "file descriptor". An open file description exists only in the kernel, and is created on open(2). A file descriptor is the userland-visible handle to this open file description. dup(2) creates a new handle (file descriptor) pointing to this same open file description. Therefore, dup(2), fork(2), etc., do not violate the mutex property of the lock, since they are duplicating the file descriptors (handles), not the open file descriptions (which actually hold the locks). What's not clear from the man pages is what happens to a locked open file description which is passed to another process via a Unix domain socket. I suspect at that point, both "processes" "hold" the lock -- which in reality simply means they both have a file descriptor referring to the same single open file description which holds the lock, thus not violating the mutex property. Though this contradicts the extensive verbiage in flock(2) which refers to "processes" as being subject to the mutex property, I suspect that is a simplification, as later text in flock(2) indicates that open file descriptions are indeed the subject of the mutex property.

Joker_vD 4y ago
In the Windows land, those things are indeed called "file objects" and "file handles" respectively, which is a much less confusing terminology.
Someone 4y ago
Thanks! Completely overlooked that they talked about ‘description’, not ‘descriptor’ in several places. It would have helped me if they pointed out that difference in a clearer way. The Linux man page says ‘Locks created by flock() are associated with an open file description (see open(2))’, and that says: “The term open file description is the one used by POSIX to refer to the entries in the system-wide table of open files. In other contexts, this object is variously also called an "open file object", a "file handle", an "open file table entry", or—in kernel-developer parlance—a struct file.”
- yrro 4y ago
  > Thanks! Completely overlooked that they talked about ‘description’, not ‘descriptor’ in several places. The classic "close reading" that man pages require...