Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ucsd!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: <25963@agate.BERKELEY.EDU>
Date: 2 Jul 89 18:21:30 GMT
References: <0933.AA0933@caleb> <1989Jun16.151408.8382@ziebmef.uucp> <25860@agate.BERKELEY.EDU> <3973@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: 65

In article <3973@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
<In article <25860@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
<> 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)

Sorry 'bout that, that was badly written. It's the same bit in the
FileInfoBlock that you use to determine if something is a link or not.
After using the FileInfoBlock, and just before calling ExNext, you
turn it on. ExNext notices it. This makes the OS cleaner (IMHO - but
I'm disgusted by BSD's plethora of calls to do the same thing, and
multiple levels of compatability and "old" calls, so my view is
biased). The people who actually write ExNext/links will have to
decided which way is better in their view, and do it that way.

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

The point is that it's not really acceptable to break old programs. On
the other hand, there may not be much choice about it. The trick is to
break as few as possible.

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

Uh, what editor? Consider:

	rename c:mycom c:mycom.old
	copy mycom c:mycom

Viola, things are broken. Of course, you could do a copy/clone instead
of a rename, but that takes more time - so you have to do everything
the hard way, or know the file is linked to. The first is
unacceptable. The second means it doesn't matter whether the link is
hard or soft; you know about it and so can be expected to deal with
it.

BTW, without hard links, using anything other than "brain-damaged" (I
assume you mean "rename" instead of "copy", as those are what break)
backup semantics is silly.  Considering how rare hard links are even
on systems that support them, it's still pretty silly.

	<mike
--
Il brilgue: les toves lubricilleux			Mike Meyer
Se gyrent en vrillant dans le guave,			mwm@berkeley.edu
Enmimes sont les gougebosqueux,				ucbvax!mwm
Et le momerade horsgrave.				mwm@ucbjade.BITNET