Path: utzoo!attcan!ncrcan!ziebmef!mcp
From: mcp@ziebmef.uucp (Marc Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Flame about AmigaDOS 1.4
Summary: LockFromFH() conflicts with hard links
Message-ID: <1989Jun19.021152.18130@ziebmef.uucp>
Date: 19 Jun 89 06:11:51 GMT
Reply-To: mcp@ziebmef.UUCP (Colin Plumb)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 82

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

My idea was to make a FileHandle work like a Unix file handle,
in that you can read, write, etc. to it, but it doesn't have a name.
This works great with hard links.  Locks do have names, but there
is no Unix equivalent, so they can have whatever semantics you like
without confusing port efforts.

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:

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

But now I'm all confused.  I still don't know whether a comment goes with a
link or a file.  Obviously, links have different pathnames but all the
same file size.  What about comments?

And do locks through different pathnames compare equal using SameLock()?

Other points...

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

Please don't screw up ExAll().  ExNext() is the real fuck-up, and you
need to *get rid* of it to really clean things up, so ExAll() is only
a convenience - it doesn't solve any problems I can think of.
So please don't add any more kludges to directory scanning.

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

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.

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.

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?

The ability to abort DOS calls is great!

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.

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

And finally, how do I get more info on the 1.4 DOS plans?

Thnaks all!
-- 
	-Colin Plumb