Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: yet another 1.4 request
Message-ID: <7187@cbmvax.UUCP>
Date: 30 Jun 89 20:16:21 GMT
References: <0933.AA0933@caleb> <1989Jun16.151408.8382@ziebmef.uucp> <18529@louie.udel.EDU> <3960@sugar.hackercorp.com> <25860@agate.BERKELEY.EDU>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 43

In article <25860@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
>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.

	Yes, links will cause some programs (mostly utilities, such as
dir/ls/etc, backup programs, search, and a few others) to rev to deal
with links.  Most programs shouldn't care.

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

	Quite true: this applies mostly to dir/ls/list programs.

> [Side note: anyone feel up to writing the ftw routine
>& tw program for the Amiga? It'd make life a lot nicer!]

	ftw I know, and shouldn't be hard to do (plus it'll be useful for
our own programs - or at least something like it).  What is tw? (I assume
it stands for tree-walk, but my sun has no man entry for it.)

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

	I suspect soft links will have timestamps.

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

	Any recursive fs-walk in a program should have stack checking
built in (yes, I know dir doesn't now, but it will).  As for non-directory non-
file entries, you won't see them unless you understand links (you'll see
what they point to).  If you understand links, you're ok.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup