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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1842 invoked from network); 31 Dec 2021 01:01:00 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2021 01:01:00 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5A3F59D006; Fri, 31 Dec 2021 11:00:59 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3AC6B9D004; Fri, 31 Dec 2021 11:00:43 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="A3V3qnz5"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D41589D004; Fri, 31 Dec 2021 11:00:41 +1000 (AEST) Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by minnie.tuhs.org (Postfix) with ESMTPS id 6C5AD9D002 for ; Fri, 31 Dec 2021 11:00:41 +1000 (AEST) Received: by mail-pj1-f48.google.com with SMTP id a11-20020a17090a854b00b001b11aae38d6so24464504pjw.2 for ; Thu, 30 Dec 2021 17:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j6qhU5ExoSDIYa0Cfb+4epqVbd/rwReKCBuHWdtw+2M=; b=A3V3qnz5urt8PyHbmPcoyBW5KE/icD7bjW2QhyywrCbg9z5EFAphg2yvVP/1vwtRW+ J+SZn1Uiyu7FJrADGFiFTpZWhjd18RZmjltNQMwsiQUal5R5wudOILD3y5cWFTDJ3Gpx 8yWbTTaB2lay3qF42FbR4RI1IUsUoOodI1EPy39v25+XVBanzAWnyMFk8TKvXZ+yw0gb U2oF6t2V+GNPQizKRDmkvq01C8c58FDbeR0gxncJ3ualI27neSaWzQNk+iLKBxN+ou58 P68aC0kY2Vzx/3zpsA49afhJfNoh5gy+feU9K/U0l4uGne2USKaNhAePPZDYHvRrylW9 KPgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j6qhU5ExoSDIYa0Cfb+4epqVbd/rwReKCBuHWdtw+2M=; b=zY/tVhxDVMBcv9LFhmw4LlfijkYzeP3OqB01jVK3sBTUPm7xQHD5OSQqHM0hL4o0S1 w8i3rWo7gyBtmKuSz3RL7M417emBdFy4539AhDJY5tnMp2MiQ9KLBu7PfJkAbAZACqtC s3WT50WrmG0HQTpmtgFBeu+WwwEIH5bMkjyyaHNH6YqC6NQudVEwdHmsTyGW5PCta4hE w1FtrXczNSIYfU5ml4EiVMi4eM/RQ+ekJN4iCy3JkfnGVnH+2xY98fYWY0XvNgZoKNuk RUI+wIryX6mEJTmbul5jXh0xqjT16pqyDyhxZcV0SMFJh7JNdYG3m7mYdy3T4xq7l42m rJDA== X-Gm-Message-State: AOAM5332Gektg2E1yGZogZP2UOHoBBRF12XYE1ee3F+cAi/uzmxbF64z ugssj89gk7QQQDtQHDoVqHllnN+uDfEtdWWHz5k= X-Google-Smtp-Source: ABdhPJywe6S6sNOkuPZzEU/UQZ4YriaBqzfsR8JGw7/uc/CmLMrY6kdH/7jPw7b5vRPwcbA9V8rFBOjeH80zqhBt7fM= X-Received: by 2002:a17:90b:f90:: with SMTP id ft16mr40758541pjb.77.1640912440826; Thu, 30 Dec 2021 17:00:40 -0800 (PST) MIME-Version: 1.0 References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> In-Reply-To: <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> From: Rob Pike Date: Fri, 31 Dec 2021 12:00:29 +1100 Message-ID: To: Bakul Shah Content-Type: multipart/alternative; boundary="00000000000024a20a05d466b37a" 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" --00000000000024a20a05d466b37a Content-Type: text/plain; charset="UTF-8" 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 wrote: > On Dec 30, 2021, at 2:31 PM, Dan Cross wrote: > > > > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o 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. > > > --00000000000024a20a05d466b37a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Grumpy hat on.

Sometimes the Unix commu= nity suffers from the twin attitudes of a) believing if it can't be don= e perfectly, any improvement shouldn't be attempted at all and b) it= 9;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 mad= e long long ago.

Grumpy hat off.

-rob


On Fri, Dec 31, 2021 at 11:44 AM Bakul Sha= h <bakul@iitbombay.org> wr= ote:
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.=C2=A0 If you store the cwd as "/foo/bar/baz/quux= ", and someone
>> renames "/foo/bar" to "/foo/sadness" the cwd-s= tored-as-a-string would
>> become invalidated.
>
> Why? Presumably as you traversed the filesystem, you'd cache, (pat= h
> component, inode) pairs and keep a ref on the inode.=C2=A0 For any giv= en
> file, including $CWD, you'd know it's pathname from the root a= s 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 pa= th.
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.


--00000000000024a20a05d466b37a--