On Tue, Feb 9, 2021 at 11:14 AM Theodore Ts'o <tytso@mit.edu> wrote:

I'm looking at you,
> fcntl locking semantics, where a close of *any* file descriptor, even
> a fd cloned via dup(2) or fork(2) will release the lock.
>

From BTSJ 57:6:


> The file system maintains no locks visible to the user, nor is there any
> restriction on the number of users who may have a file open for reading or
> writing. Although it is possible for the contents of a file to become
> scrambled when two users write on it simultaneously, in practice
> difficulties do not arise.  We take the view that locks are neither
> necessary nor sufficient, in our environment, to prevent interference
> between users of the same file. They are unnecessary because we are not
> faced with large, single-file databases maintained by independent
> processes. They are insufficient because locks in the ordinary sense,
> whereby one user is prevented from writing on a file that another user is
> reading, cannot prevent confusion when, for example, both users are editing
> a file with an editor that makes a copy of the file being edited.
> There are, however, sufficient internal interlocks to maintain the logical
> consistency of the file system when two users engage simultaneously in
> activities such as writing on the same file, creating files in the same
> directory, or deleting each other’s open files.


(end)



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
How they ever reached any conclusion at all is starkly unknowable
to the human mind.        --"Backstage Lensman", Randall Garrett