Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eris.berkeley.edu!mwm
From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: yet another 1.4 request
Message-ID: <25860@agate.BERKELEY.EDU>
Date: 28 Jun 89 22:47:13 GMT
References: <0933.AA0933@caleb> <1989Jun16.151408.8382@ziebmef.uucp> <18529@louie.udel.EDU> <3960@sugar.hackercorp.com>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Organization: Missionaria Phonibalonica
Lines: 87

In article <3960@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
<In article <18529@louie.udel.EDU>, new@udel.EDU (Darren New) writes:
<> always change ExNext to look for the linked-to file and make NewExNext
<> return more status information.
<
<Yes. This is implicit in the idea of links. What to do with the file name
<portion of the feild is interesting... magically turn it into the name
<of the link or not? I think yes, to avoid confusing directory searchers.

First, you don't need a NewExNext. Just have ExNext check the magic
link bit when it comes to a link. If the bit is on (set by the user),
it just hands back the link block, which contains nothing but the file
name and the name of the file it's a link to. If the bit is off (which
it should be for all current binaries), it gets a FileInfoBlock for
the file the link points to, and then plugs the name from the link FIB
into the new one, and hands that back to the user.

<> But then what happens when the soft-link
<> and the linked-to file are in the same directory? We wind up seeing and
<> maybe trying to delete the same file twice?
<
<Depends on just what we do, but in general, yes.

That is the way things should behave. If you've got two copies of the
same file in a directory now, you see them twice. The same should
apply to links.

<> I think this is not quite so easy as it seems. (It never is, is it? :-)
<
<But it's not as complex as it seems.

I haven't seen anybody mention fixing the utilities to match this.
That's going to make things harder. Especially if the default behavior
is to follow the link.

First rule: _everything_ that determines it's got a link should report
where it's a link to. I.e. - instead of saying "this is a link", they
should all say "this is a link to <name>". You quickly get annoyed at
utilities that don't do that.

Second rule: the default behavior for things that walk the file system
tree must be chosen carefully (thought experience dictates that not
following links is usually correct). If it follows links, it must keep
a stack of all the directories it's currently visiting, and check to
make sure it's not going to revisit one of those (this is why not
following links is usually correct). In addition, each such utility
must be carefully examined to see if it makes sense to add an option
to do the other thing with links (the answer is usually "yes"), and
deal with that.  [Side note: anyone feel up to writing the ftw routine
& tw program for the Amiga? It'd make life a lot nicer!]

Third rule: Backup/restore programs must be made to undestand links,
and deal with them properly. Unless you timestamp the link, this means
saving a copy of the link (not the file it points to) every time. This
is just a disk block or two, so that's no big deal.

Remember, you're introducing a new file type into the system. Every
program that looks at a files type must be made to deal with this
type. You also have to make sure that the default behavior doesn't
make existing programs die in strange ways.

Now, Peter - care to define the default behavior so that my rprot
(recursive protect - changes permissions on a tree) program won't 1)
get upset when it finds a file that's not a directory or data file,
and 2) won't die for lack of stack space if I feed it a tree with a
link back to the top of the tree?

Now, on users being able to delete things out from under soft links.
That doesn't confuse the applications: they just find they can't open
files. A "list" on the file (gotta check the permissions, ya'know)
should show it's a soft link to a file that doesn't exist.

On the flip side, hard links make it possible to "update" a file, and
not have everyone using the updated version - because they have hard
links to the original. All you have to do is delete or rename the old
version before copying the new version into place. Soft links don't
have that problem - they refer to a file by name, so when you open the
symlink, you always get whatever file has that name. This more than
makes up for the ability to delete a file without mentioning it by
name.

	<mike
--
Kiss me with your mouth.				Mike Meyer
Your love is better than wine.				mwm@berkeley.edu
But wine is all I have.					ucbvax!mwm
Will your love ever be mine?				mwm@ucbjade.BITNET