🚀 go-pugleaf

In article <401@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
<Naturally this effect could duplicated by a new flag to a link command,
<like "ln -sc file1 file2" to check to make sure the original exists before
<creating the soft link.

Hey, I like that. Only I'd just make it one flag: "ln -c file file2".


<It may be that *everything* I'm saying is useful about hardlinks on Unix
<can be gotten via variations on the theme of softlinks in a similar way,

This is the first thing I've seen that points in what I consider the
right direction. Hard links & soft links have a large area of overlap
when it comes to actual use. It'd be nice to find a single concept
that covers everything.

<Aw, that's not fair. I thought it was a pretty clear example. The last
<time it happened, someone said "there's a compiler bug triggered by tmp.c,
<check it out but don't screw with it because I'm still using it." Being
<thrifty, I make a link to it rather than copying it.

And then, when <someone> edits tmp.c, they overwrite (depending on the
editor) your link with something that no longer triggers the bug. Of
course, soft links do the same thing.

Also, you can only do this thing on small systems. Large systems tend
to have users files scattered around multiple disks - so you have to
use a soft link if you still want to use a link.

<So? In real life, root doesn't do that. Root has the *ability* in order
<for the semantics of mv, mkdir, etc to work correctly. It is not
<otherwise exercised.

Hey, Doug - where did you get the virtual reality?

True, I don't have hard links to directories on any of my current
systems. But that's because they all support soft links. On systems
that didn't have soft links (ah, the days when Unix was fast on submip
machines), I made hard links to directories. I'd do it again under the
same circumstances.

On the other hand, I knew what I was doing, and used that ability
carefully. I'm _very_ glad T & R took it away from everday users
before I got to Unix.

Along the same lines, someone said that people don't create soft links
to files. This is equally false - I do. Usually when I want a single
command from someones private bin, want to make sure I always have the
latest version, and don't want to spend the space on it. Soft links
are the only way to do that. Of course, I lose when the file is
deleted, but that's better than losing when it's updated.

Of course, on the system I work on most of the time, we have users on
13 file systems. So odds are 12-1 that I won't be able to make a hard
link to files in a random users directory anyway.

What I'm curious about is why this fascination with doing thing the
way Unix did them? Just because Unix was the first popular OS to do
links doesn't mean it did them right - in fact, being first means it
probably did them wrong. As has been pointed out here, hard & soft
links both have problems. To me, something that sits in the middle
would be much better. Oddly enough, AmigaDOS has that; there's just no
way to put a lock into the file name space. So how about adding it,
like so:

1) Creating a link basically creates a soft link, except it also bumps
the link count for the file it's linked to.

2) Opening a link causes a lock to the original file to be saved,
which you can now get to via the link name. This should work much like
an automatic assign, or a "link cache." (Hmm - on second thought, this
doesn't seem like such a good idea. I'll leave it here anyway.)

3) You can't delete or rename a file unless it's link count is zero.

4) Creating a link to a link chases down the real file, uses it's name
and bumps it's link, all so

5) You can always delete or rename a link.

First note: this shouldn't be a lot harder than doing Unix-style soft
links - except for the cache...

Second note: The default behavior of link is to fail if there isn't an
original file; it's got to bump a link count. It ought to be possible
to force a link to a nonexistent file. Such things should result in
failure if opened. 

Third note: Making links go "through" links is to get more of the hard
link semantics into the links. It also menas you never have to chase
through multiple links (or, worse yet, backwards through multiple
links). 

Fourth note: not being able to rename is the key. This is where the
difference between hard and soft links really becomes apparent.  Hard
links aren't affected by the rename. Soft links are.  Both behaviors
can be confusing/desirable at times. So I claim that the behavior of
not permitting it to happen is correct - you make whoever is doing the
rename find & deal with the files that are linked to the original as
is apropriate for them. That way, you don't get any unexpected effects
(either old copies still floating around, or open failures in the
future).

Fifth note: a tool needs to be provided for dealing with all the links
of a file during a rename.

Sixth note - and I just realized it: dealing with links from
demountable volumes is going to be a bitch.

I realize this is all so much hot air; 1.4 links could already be set
in stone, so nobody who matters will be listening.

	Sigh,
	<mike
--
And then up spoke his own dear wife,			Mike Meyer
Never heard to speak so free.				mwm@berkeley.edu
"I'd rather a kiss from dead Matty's lips,		ucbvax!mwm
Than you or your finery."				mwm@ucbjade.BITNET