🚀 go-pugleaf

In article <25860@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
> 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 off (which
> it should be for all current binaries...

It took me a second to figure out that the magic link bit refers to. It's
something attached to the program, or in the ExNext call. How does this differ
from having two ExNexts? (ExNext and ExNextLink, if the name NewExNext offends)

> First rule: _everything_ that determines it's got a link should report
> where it's a link to.

Yes.

> 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).

Yes.

> Third rule: Backup/restore programs must be made to undestand links,

Yes.

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

By default, call ExNext(..., GIMME_LINKS) or ExNextLink(). That is,
don't follow links.

Old programs may be broken by links... I know Browser will be. This is
not a reason not to implement them... just don't put any on the distribution
disks, or ship programs that depend on them for a while.

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

That's the best solution, and shouldn't cause problems except for people
who don't use the CLI.

Which is quite a few people. But they're unlikely to be using links anyway.

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

Only if the editor they're using has brain-damaged backup semantics.

And sometimes it's an advantage to be able to break the link.

But not in AmigaDOS.
-- 
Peter "Have you hugged your wolf today" da Silva      `-_-'
...texbell!sugar!peter, or peter@sugar.hackercorp.com  'U`