From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12829 invoked from network); 9 Feb 2021 17:32:46 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 9 Feb 2021 17:32:46 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4C8A095041; Wed, 10 Feb 2021 03:32:43 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AB4C394F19; Wed, 10 Feb 2021 03:32:11 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ccil-org.20150623.gappssmtp.com header.i=@ccil-org.20150623.gappssmtp.com header.b="hJvTccuo"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id CBB2D94F19; Wed, 10 Feb 2021 03:32:07 +1000 (AEST) Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by minnie.tuhs.org (Postfix) with ESMTPS id EAC2494F18 for ; Wed, 10 Feb 2021 03:32:06 +1000 (AEST) Received: by mail-qk1-f181.google.com with SMTP id t63so18786279qkc.1 for ; Tue, 09 Feb 2021 09:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cVofzgQEgpnObtPmpaZFfgy9Fr1JSHpIZy+5GLeXiz8=; b=hJvTccuo4J2srNu+Nl5AulbkIiznRJFUruFZGS8DcqgnpI6kW5Xjj7itm0yJtyLxYD WMe7IgKX86Ag3g+xeziGpPhOB+p/JiwimP04qqbz5gcsFgKhVuXwVReG0T5ZstqQWgj7 BnEomWGiPMekZMu55dbWWF7wHYsJYH4PJ8WCUh+aJmHIccM3mUCvtvBEvpwMJlpA+ivH U+sqO8eO/bHPCxaWAwngcM3Rb7cPv5bDdl++hJlXIqe2l4at5ZMMxJArkOQCjXyFDRkv FGNwQGNoLkNA5prjobd/SMt2Cj0BouA51cv3kIQt+3eyjHPuiVPsKqe2VCNIBUTjz78c bTcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cVofzgQEgpnObtPmpaZFfgy9Fr1JSHpIZy+5GLeXiz8=; b=Xl4VOdMloE2/8GfiuOMyfrPdUQv2Tuw2PaAxFeDaM5S1g+3bTfasNaxVYN6jr3yKrl vOdpZ+PYJFjsAyLQlrqVvlccX7yaeCaniSie/BcfLPOG/eGTePltY1BNJX3uryh/JdmW 3eYQZUuMkn+z565JMtNdPR44uh50IvVqyt0DF7Ot8mbe7Q+lQTzHQ1FBOU83lksjbT2i q05ECr/LSKs89FzP6SvidZbg63rnr7hzUpIbdGvlG14WavlHsmMTBtRZ2I6eBRnT1cTd Dx8V9Gt4kLQ1Py+Oj37mnflmoRcg2yqivalOM/3AM14r9IbPmpZ7LjRGM8e2vr5XbDvc tWAg== X-Gm-Message-State: AOAM531CKkP+jZuazMYv2UKKVhr9P4jjZVFTNIv0pmgKhCr+jnO7kAQ+ jkePQut3djV1Ae5DU/xoBj3Llog9uBjVwqNDjprULw== X-Google-Smtp-Source: ABdhPJwzJrTkxsY1hjukLfuaHxhO9WP/HvrpsimmkoeD/VtQDM5RnBHQsEs/csIEFWxgTdXlXjEP7fjjeKMKYTYOVxE= X-Received: by 2002:a37:418d:: with SMTP id o135mr22685245qka.426.1612891925931; Tue, 09 Feb 2021 09:32:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Cowan Date: Tue, 9 Feb 2021 12:31:52 -0500 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="0000000000004e7ef305baeaaa96" Subject: Re: [TUHS] Macs and future unix derivatives X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000004e7ef305baeaaa96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 9, 2021 at 11:14 AM Theodore Ts'o 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 o= r > 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 editi= ng > a file with an editor that makes a copy of the file being edited. > There are, however, sufficient internal interlocks to maintain the logica= l > 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=E2=80=99s 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 --0000000000004e7ef305baeaaa96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 9, 20= 21 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:
=C2=A0
The file system maintains no locks visible to the user, nor is th= ere any restriction on the number of users who may have a file open for rea= ding or writing. Although it is possible for the contents of a file to beco= me scrambled when two users write on it simultaneously, in practice difficu= lties do not arise.=C2=A0 <= span class=3D"gmail_default" style=3D"">We take the view that locks = are neither necessary nor sufficient, in our environment, to prevent interf= erence between users of the same file. They are unnecessary because = we are not faced with large, single-file databases maintained by independen= t 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 ex= ample, both users are editing a file with an editor that makes a copy of th= e file being edited.
There are, however, sufficient internal interl= ocks to maintain the logical consistency of the file system when two users = engage simultaneously in activities such as writing on the same file, creat= ing files in the same direc= tory, or deleting each other=E2=80=99s open files.
=
(end)


<= /div>
John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0http://vrici.lojban.org/~cowa= n =C2=A0 =C2=A0 =C2=A0 =C2=A0cowan@cc= il.org
How they ever reached any conclusion at all is starkly unknow= able
to the human mind. =C2=A0 =C2=A0 =C2=A0 =C2=A0--"Backstage Len= sman", Randall Garrett

--0000000000004e7ef305baeaaa96--