Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!voder!pyramid!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Flame about AmigaDOS 1.4
Message-ID: <7184@cbmvax.UUCP>
Date: 30 Jun 89 18:20:43 GMT
References: <1989Jun19.021152.18130@ziebmef.uucp>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 107

In article <1989Jun19.021152.18130@ziebmef.uucp> mcp@ziebmef.UUCP (Colin Plumb) writes:
>Okay, Mr. Beats... you say you want to put hard links in 1.4
>("Filing System Enhancements for V1.4," DevCon), but I
>can't figure out how you do it.  Or should I be talking to
>Randell?  Or someone else?  Anyway, other FS hackers might
>be interested, so...

	Hard links are Steve.  Soft links are (mostly) me.

>Now you go and give us this LockFromFH() call, which turns a FileHandle
>into a lock... which we can turn into a pathname.  Please tell me
>what is ther result of the following operations:

	Returns a lock on the object associated with the filehandle.

>Create file a/b.
>Make links c/d and e/f to a/b.
>Open files a/b, c/d, and e/f - call these file handles 1, 2, and 3.
>Delete link a/b.  While you're at it, delete directory a, rename
> directory c to x, file x/d to x/y, and file e/f to foo/bar/baz/quux/f.

	a/b may not be deletable.  This is not Unix, so don't expect 100%
Unix semantics.  However, it's mostly steve's call.

>Print the path names for file handles 1, 2, and 3.
>
>What path name do you expect to come from these?  My idea was to associate
>a given *pathname* with a lock, so you couldn't delete a *link* that had
>locks on it (although you could rename it), but to leave FileHandles alone
>and nameless.  You could, in fact, delete an open file's last link and have
>Unix behaviour.  (I hear cheers...)

	Personally, I hate that behavior.  Unix is not the be-all and end-all
of system designs.  I want something better and more consistant (things like
links in unix are pretty dreadful, though useful, hacks.)  I want more
consistent semantics between hard and soft links, or perhaps even no hard
links at all.  Those of you that care: what would be bought on the amiga
by having hard links, if we already had soft links?

>Personally, I still think a late-binding PATH: device is cleaner than
>AssignPath(), and more flexible to boot.

	The problem with PATH: handlers is that they must remain part of
all transactions started through them.  If you set C: to PATH:..., then
all loading of C: commands must pass every packet through the PATH:
handler.

	We may provide this in the future.  However, some of the things
dealt with by PATH: (though not all) can be handled by soft links.

>What in the heck is a buffered seek, as opposed to a normal seek?

	It's a seek that understands buffered filehandles.  The buffering
stuff is kind of like the different "levels" of stdio IO calls.  (Very like
them, in fact).

>Why dies GetProgramDir return a lock on the *directory* instead of one on
>the *executable*, which would seem to be much more useful, as it would
>also give you the name and let you add extra junk to the one file after
>the end of the LoadSeg() hunks.

	One of this, two of that.  (You have the name of the executable).
I'll consider it.

>What does a struct NotifyRequest do?  Why won't even Amiga-Amiga NFS's
>support it?  It's a *really* useful thing, and would be great if
>it's done properly.

	Amiga-Amiga FS's could (NFS wouldn't since notification demands
having "state", and NFS itself is stateless (and doesn't do notification).
The point is to beat on people not to lock themselves out of a heterogenous
networked environment.

>Is NameFromLock() guaranteed to be atomic?  A sequence of ParentDir() and
>Examine() calls, can, if the names of various componenets are being
>changed on the fly, produce a "pathname" that never existed, although
>each component did at one time.  Does NameFromLock() avoid this race
>condition?

	It may, final design isn't done yet.  I'll keep it in mind.

>The ability to abort DOS calls is great!

	That's probably not going to be in there, unless I have a brainstorm
and come up with a workable solution.

>And having a better message system would be *really* nice.
>You could somehow tell AmigaDOS which interface I'm using, and it
>would send the apropriate packet.  Messy for you, but do *NOT*
>require that every handler support the old packets, or nobody will
>bother with the new kind.

	For 1.4 old packet support is highly recommended, perhaps even
required.  Post 1.4 will probably not require BCPL packets.

>How about creating a special daemon process whose job it is to
>load libraries into the system.  So my task can call OpenLibrary()
>without worrying about the location, and if the library isn't
>resident, a message gets sent to this daemon, which loads it for
>me and has any wierd stuff AmigaDOS wants.  Or just fix the relavent
>AmigaDOS calls not to need a process...

	Being thought about, and important issue.  Also impacts OpenDevice
and OpenDiskFont.

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