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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7242 invoked from network); 31 Dec 2021 01:46:21 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2021 01:46:21 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A518A9D008; Fri, 31 Dec 2021 11:46:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3C5AA9D006; Fri, 31 Dec 2021 11:45:52 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=iitbombay-org.20210112.gappssmtp.com header.i=@iitbombay-org.20210112.gappssmtp.com header.b="52Q0hA5U"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 7605A9D006; Fri, 31 Dec 2021 11:45:48 +1000 (AEST) Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) by minnie.tuhs.org (Postfix) with ESMTPS id 338859D002 for ; Fri, 31 Dec 2021 11:45:46 +1000 (AEST) Received: by mail-oo1-f43.google.com with SMTP id y13-20020a4a624d000000b002daae38b0b5so8321511oog.9 for ; Thu, 30 Dec 2021 17:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UR444hPB2Akn4K0OCm4u0wI3I4O2/jVIjXhNY191IkI=; b=52Q0hA5UGGUcUoSLwyt+t+Br6oHT4KplXnuCJVF5Zy0AyunXsQ1tMLzWhq8EhDESjM /B5rPmGc2fJa9w2XSzhrnepQ0Wi+Wk9FwSj/fOccuvKzgTcJhe8dSYIJmtk1WLKj+jLa I47vnt2Mm38IGwIzaNsQM8Q1qY3NAyDIPs8I9JIrn5vJB1lwR1tfeL01BIh9uv27WabS sjZASK76yZy0wVuIURmqzuXbTJF2jV3sOnQ6ZccJRCFRiNJSU566qZSd0q+urpn8rrXq RJtgWX57mD1bJ0tfTFaIxBGn2Nr7T2vWhOGX5R1ftJdAdm2+/6gU9ZXOpDr65VU+++/5 6oTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UR444hPB2Akn4K0OCm4u0wI3I4O2/jVIjXhNY191IkI=; b=UZhfxcjAxhMxVtOpjZssMhmTq41KLyWXJR/LE0G4z6Gvmta1z/r7jXgidG2G+hMBHf euZNM8LnCq8IL2b4JKNl4YW7hFa51I6tOMSzb7xDSqED4HzcILDAbtSwi5bA+nBgzMW4 VXm4xbArRTy8MBxTPObmQhU8qGJct9moulCjKzjZIwS3Lu31TAdgr0VXdBwX97N13A8e uZ9kxLhPS2t6x62qbPo4CcqJhrBVPtNOwlx1G0DyE+P+QN9vvJWsxWZohwdKBo7ws8Bv zznED3IR4w8a9mVRmPhiCgElXZyQTJ4qy4NtUINqft8yc7vVle5fiaK7YTx9dw1njEsm JDXw== X-Gm-Message-State: AOAM533VXftexiU/uQwVfo8gAJcRYiVN0cdlH9Cu/irxs4jCNtQC6uDS FR1tcYl4J5eX7kvcU+UeuK/cHg== X-Google-Smtp-Source: ABdhPJxEH71ZlDOUKPQtmk1UKvJAPe2ThVW2YiBMtDGmzaqKUV1RD8OqmHpaPmHi+VKAW2lVlo2RYw== X-Received: by 2002:a05:6820:622:: with SMTP id e34mr21280286oow.19.1640915145075; Thu, 30 Dec 2021 17:45:45 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id f59sm5169695otf.9.2021.12.30.17.45.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Dec 2021 17:45:44 -0800 (PST) From: Bakul Shah Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_76CAC6F2-D05F-4ED2-A694-14F8CBE127AD" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Thu, 30 Dec 2021 17:45:43 -0800 In-Reply-To: To: Rob Pike References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> X-Mailer: Apple Mail (2.3693.40.0.1.81) Subject: Re: [TUHS] moving directories in svr2 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 , Noel Chiappa Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --Apple-Mail=_76CAC6F2-D05F-4ED2-A694-14F8CBE127AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ? I was just explaining Ts'o's point, not agreeing with it. The first = example I gave works just fine on plan9 (unlike on unix). And since it doesn't = allow renames, the scenario T'so outlines can't happen there! But we were discussing Unix here. As for symlinks, if we have to have them, storing a path actually makes = their use less surprising. > We're in the 6th decade of Unix and we still suffer from unintended, = fixable consequences of decisions made long long ago. No argument here. Perhaps you can suggest a path for fixing? > On Dec 30, 2021, at 5:00 PM, Rob Pike wrote: >=20 > Grumpy hat on. >=20 > Sometimes the Unix community suffers from the twin attitudes of a) = believing if it can't be done perfectly, any improvement shouldn't be = attempted at all and b) it's already done as well as is possible anyway. >=20 > I disagree with both of these positions, obviously, but have given up = pushing against them. >=20 > We're in the 6th decade of Unix and we still suffer from unintended, = fixable consequences of decisions made long long ago. >=20 > Grumpy hat off. >=20 > -rob >=20 >=20 > On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah > wrote: > On Dec 30, 2021, at 2:31 PM, Dan Cross > wrote: > >=20 > > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o > wrote: > >>=20 > >> The other problem with storing the path as a string is that if > >> higher-level directories get renamed, the path would become > >> invalidated. If you store the cwd as "/foo/bar/baz/quux", and = someone > >> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string = would > >> become invalidated. > >=20 > > Why? Presumably as you traversed the filesystem, you'd cache, (path > > component, inode) pairs and keep a ref on the inode. For any given > > file, including $CWD, you'd know it's pathname from the root as you > > accessed it, but if it got renamed, it wouldn't matter because you'd > > have cached a reference to the inode. >=20 > Without the ".." entry you can't map a dir inode back to a path. > Note that something similar can happen even today: >=20 > $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd .. > cd: no such file or directory: .. >=20 > $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b > ls: ../b: No such file or directory >=20 > You can't protect the user from every such case. Storing a path > instead of the cwd inode simply changes the symptoms.=20 >=20 >=20 --Apple-Mail=_76CAC6F2-D05F-4ED2-A694-14F8CBE127AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ?
I was just explaining Ts'o's = point, not agreeing with it. The first example I
gave= works just fine on plan9 (unlike on unix). And since it doesn't = allow
renames, the scenario T'so outlines can't = happen there! But we were
discussing Unix = here.

As for = symlinks, if we have to have them, storing a path actually makes = their
use less surprising.

We're in the 6th decade of Unix = and we still suffer from unintended, fixable consequences of decisions = made long long ago.

No argument here. Perhaps you can suggest a path for = fixing?

On Dec 30, 2021, at 5:00 PM, = Rob Pike <robpike@gmail.com> wrote:

Grumpy hat on.

Sometimes the Unix community suffers from the twin attitudes = of a) believing if it can't be done perfectly, any improvement shouldn't = be attempted at all and b) it's already done as well as is possible = anyway.

I = disagree with both of these positions, obviously, but have given up = pushing against them.

We're in the 6th decade of Unix and we still suffer from = unintended, fixable consequences of decisions made long long = ago.

Grumpy = hat off.

-rob


On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah <bakul@iitbombay.org>= wrote:
On Dec 30, 2021, at 2:31 PM, Dan = Cross <crossd@gmail.com> wrote:
>
> On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso@mit.edu> wrote:
>>
>> The other problem with storing the path as a string is that = if
>> higher-level directories get renamed, the path would become
>> invalidated.  If you store the cwd as "/foo/bar/baz/quux", = and someone
>> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string = would
>> become invalidated.
>
> Why? Presumably as you traversed the filesystem, you'd cache, = (path
> component, inode) pairs and keep a ref on the inode.  For any = given
> file, including $CWD, you'd know it's pathname from the root as = you
> accessed it, but if it got renamed, it wouldn't matter because = you'd
> have cached a reference to the inode.

Without the ".." entry you can't map a dir inode back to a path.
Note that something similar can happen even today:

$ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
cd: no such file or directory: ..

$ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
ls: ../b: No such file or directory

You can't protect the user from every such case. Storing a path
instead of the cwd inode simply changes the symptoms.



= --Apple-Mail=_76CAC6F2-D05F-4ED2-A694-14F8CBE127AD--