mcp@ziebmef.uucp (Marc Plumb) (06/19/89)
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 Plumbmcp@ziebmef.uucp (Marc Plumb) (06/20/89)
I just found the notification information in the V1.4 preferences docs, and I think it's generally good. FileRequester people will love it. Here's a summary... You can ask to be notified when a file or directoy changes. In the case of a file, you get notified when it's closed after a write. You fill out a Notify request structure and pass it to StartNotify() (or do the equivalent packet thingie). You aren't allowed to mess with it until you call EndNotify(). You can be notified by signal (when the change occurs, your process gets a certain signal, simple & useful for file requesters and the like, which only want one thing at a time) or by a message, which sends a message giving more information. With the message version, you can ask not to be notified again until you've replied to the message. You can also have part of the file you're interested in copied to a buffer. This has race conditions unless you use the only-one-message-at- a-time option. Off hand, I can't think of any real problems implementing this in a network environment. Good job, Steve! (And I apologise if my comment about ExAll() was a bit abrasive - I was in a *really* bad mood about LockFromFH(). What I said is mostly true, but there are lots nicer ways to say it. Since the ExNext() call exists, implementing a file system is a royal pain in the ass. I can't think of a way to improve the situation by adding more features, only by deleting ExNext(). So just please don't make our lives harder. Thanks!) ((But my nasty comments about hard links still apply - what the hell is going on here? Hard links means that a file does not have a unique name. Maybe if you described how you intend to implement it by adding features to the current DOS, I'd understand.)) -- -Colin
page%swap@Sun.COM (Bob Page) (06/21/89)
The stuff handed out at DevCon was preliminary info, to solicit feedback -- feedback that should go to Commodore, not to USENET. Nothing you read in the documents is true. At least not until ship. CBM had filesystem links early in the stages of 1.3, but pulled them out. There's nothing to say they won't do it again. Everything is subject to change. So lay off and act responsible. Send e-mail to cbmvax!suggestions if you have something to say. And don't flame about something that doesn't exist. ..bob
rap@ez.ardent.com (Rob Peck) (06/21/89)
In article <1989Jun19.130933.26364@ziebmef.uucp> mcp@ziebmef.UUCP (Colin Plumb) writes: >I just found the notification information in the V1.4 preferences docs, >and I think it's generally good. FileRequester people will love it. >Here's a summary... It was my understanding (and no doubt that of many of the other developers) that the information contained in the DEVCON notes was to be treated as "confidential" and is for the benefit of the developers that you are able to find out what is coming, or at least what is purported to be coming. One thing one would not want to do is to let on to all of your competition things that you are working on. Or, just as bad, get folks excited about something that never quite comes to pass. Vaporware gets results, though not what you'd really want. I suggest that if we want CBM to continue to be relatively open about their plans, which in turn help us to plan our software efforts and of course our own potential profitability, that we keep quiet about things that we've been told in confidence and let the marketeers control when the actual announcements happen. So far I have not seen any CATS folks officially announcing things such as mentioned by those who obviously have access to the DEVCON notes for 1.4. This is not doing any of us any good. Lets restrict the discussion to unsubstantiated rumors and suggestions for OTHER, lets call them improvements, that may (or may NOT) already be in process. This is "our" machine of choice -- lets help CBM keep it out there so we can continue to enjoy it! Rob Peck
jesup@cbmvax.UUCP (Randell Jesup) (07/01/89)
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