Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Adam Thornton <>
To: Bakul Shah <>,
	Computer Old Farts Followers <>
Subject: Re: [COFF] [TUHS] moving directories in svr2
Date: Thu, 30 Dec 2021 19:23:36 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 4676 bytes --]

Moving to COFF, perhaps prematurely, but...

It feels weird to be a Unix native (which I consider myself: got my first
taste of Irix and SVR3 in 1989, went to college where it was a Sun-mostly
environment, started running Linux on my own machines in 1992 and never
stopped).  (For purposes of this discussion, of course Linux is Unix.)

It feels weird the same way it was weird when I was working for Express
Scripts, and then ESRX bought Medco, and all of a sudden we were the 500-lb
Gorilla.  That's why I left: we (particularly my little group) had been
doing some fairly cool and innovative stuff, and after that deal closed, we
switched over entirely to playing defense, and it got really boring really
fast.  My biggest win after that was showing that Pega ran perfectly fine
on Tomcat, which caused IBM to say something like "oh did we say $5 million
a year to license Websphere App Server?  Uh...we meant $50K."  So I saved
them a lot of money but it sucked to watch several months' work flushed
down the toilet, even though the savings to the company was many times my
salary for those months.

But the weird part is similar: Unix won.  Windows *lost*.  Sure, corporate
desktops still mostly run Windows, and those people who use it mostly hate
it.  But people who like using computers...use Macs (or, sure, Linux, and
then there are those weirdos like me who enjoy running all sorts of
ancient-or-niche-systems, many of which are Unix).  And all the people who
don't care do computing tasks on their phones, which are running either
Android--a Unix--or iOS--also a Unix.  It's ubiquitous.  It's the air you
breathe.  It's no longer strange to be a Unix user, it means you use a
21st-century electronic device.

And, sure, it's got its warts, but it's still basically the least-worst
thing out there.  And it continues to flabbergast me that a typesetting
system designed to run on single-processor 16-bit machines has, basically,
conquered the world.


P.S.  It's also about time, he said with a sigh of relief, having been an
OS/2 partisan, and a BeOS partisan, back in the day.  Nice to back a
winning horse for once.

On Thu, Dec 30, 2021 at 6:46 PM Bakul Shah <> wrote:

> ?
> 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:
> 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.

[-- Attachment #1.2: Type: text/html, Size: 6339 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

COFF mailing list

           reply	other threads:[~2021-12-31  2:24 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).