Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!ucbvax!jade!eris!mwm
From: mwm@eris.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: File naming conventions.
Message-ID: <5287@jade.BERKELEY.EDU>
Date: Thu, 1-Oct-87 08:29:14 EDT
Article-I.D.: jade.5287
Posted: Thu Oct  1 08:29:14 1987
Date-Received: Sat, 3-Oct-87 08:45:44 EDT
References: <503@louie.udel.EDU> <1929@umd5.umd.edu> <775@sugar.UUCP> <5218@jade.BERKELEY.EDU> <837@sugar.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 145

Rather than do a point by point, I'll lay out the way I read the
AmigaDOS file system. As with Unix, I get a different meaning than
Peter does - noticably influenced by the differences in the way I
read the Unix file system.

1) Directory names: starts at one of two places, the root of a
device or the current directory. The first case is signified by ":" in
the file name, the second by that not happening. The directory name
stops at the last "/" or ":", and is followed by the name of the file.

2) As a special case, the directory name "/" in any directory means go
to the parent of that directory if it exists. If it doesn't exist,
it's an error.

This is nearly identical to my reading of the Unix file system, except
that ":" replaces "/" to indicate the root, and that "/" to get to a
parent is a special case instead of every directory having entries
pointing to "." and "..".

So, rebuilding Peter's table using the above, we see:

Concept		Unix		AmigaDOS
root		"/"		[^:/]*:		(not sure about the regexp)
filename	[^/]*		[^:/]*
directory	.*/		[^:/]*:[^:]*/
current		""		""
		./		missing
parent		../		/

Both suffer from there not being documentation that tries to explain
how the parts of the file name space fits together. I suspetc that the
designers of the two file systems didn't worry about it, and just put
togehter something that worked.

Question, then some answers:

You keep claiming that utilities pop you up a level. Could you name
them? The only things I've ever had trouble with putting things in the
wrong directory are DPaint II (file requesters remember devices, but
not paths) and Manx cc (doesn't put .o files in the currenct directory).

<> <If you're going to do this then why not go all the way
<> <to the much simpler UNIX syntax.
<> 
<> This doesn't work on other devices, and will give fits to some
<> drivers. And you may want those programs to be able to use device
<> drivers (conman being the one that leaps to mind).
<
<But other devices (CON:, etc...) aren't directory structured. The file name
<is just a string. The slashes there just give you a convenient way of
<seperating symbols. Comma would do just as well, but slash is already
<used that way so why not?

No, pipe: is directory structured. Or at least supports the packets
needed by the dir command.

And that's besides the point. If you're going to make "device:/"
identical to "device:", you should do it for *all* devices. That's
what consistency is all about. Since you manifestly *can't* make it
mean the same thing for all devices, you shouldn't try to do it for
one device in particular.

<The question becomes "is this a file or is this a string I'm passing to
<some magic driver". Presumably you're not going to be cd-ing to CON:.

Uh, please distinguish between a "file" and "string being passed to a
magic driver", where magic driver is the AmigaDOS file system handling
code?

<Summary: The fact that it's possible to even have this discussion implies
<that there's something wrong with the semantics of the Amiga file system. I
<think that the basic problem is that "the name of a file" and "the name of
<a directory" aren't the same thing.

Of course, I use the same fact to conclude that there's something
wrong with the Unix file system :-).

<Unfortunately the documentation and programs treat foo and foo/ the same

In other words, if we fixed the documentation, that'd fix the
"problems" you have with the AmigaDOS file system. Except we'd still
need a real name for the current directory.

Let's see - for Unix, there's no distinction between a directory and a
file, going so far as to allow you to read files like anything else.
This led to lots of broken programs when the file system format
changed. Except for rm, of course. And a few other odd things.

In AmigaDOS, there's a definite difference between a directory and a
file. But some programs go out of there way to hide this from you (in
many cases - like cp/copy, for instance - in about the same way that
Unix utilties do).

On VMS, the distinction is hard. The directory has a different name
from the file - the directory being [x.y.z] and the file being
[x.y]z.dir. This makes it impossible to have a logical name that
refers to a directory in both modes.

All three methods have some problems. Then again, I don't think
any of the designers ever tried to come up with consistent semantics
for the file systems - they just did something that worked. Instead of
just trying to clone Unix onto AmigaDOS, how about trying to get to a
system that doesn't have any of the problems of the three?

[Entering blue sky...]

<I realise that there is a bit of a conflict with Examine/ExNext
<in that you would not be able to get all the ExNext info this way. The best
<way of dealing with this is to require the user to explicitly do another
<Examine on the names returned by ExNext to get that info, and just have
<ExNext fill in the filename.

Not a bad idea, but what happens if you the thing you examined was a
directory? Does the next ExNext follow it, or go back to the old
directory?

One solution would be:

<But this *would* break stuff, so how about a call that works like ExNext but
<just fills in the filenames? This wouldn't give you much of an improvement
<right away (except for the Workbench, which would presumably use the new
<calls, and the "new dir" that would come on the new set of disks (2.0?)), but
<as programs started using the new calls things would start getting MUCH faster. 

Until you rewrite the DOS to not store names in headers along with all
the rest of the stuff handed back by Examine, *nothing* would gain by
this. Might as well rewrite the DOS first, then add the call to fetch
the next name from a directory.

<[ENTER gritch mode]
<
<"dir opt a" is a kludge. Other programs use the keyword "all" for this. Why
<ever use anything but keywords for options once you've started?

Probably for the same reason that some Unix utilities use "v" to get
more information, whereas others use "l", and some require the "-",
and others don't, and some utilities let you stack flags, and others
don't, etc. - different people wrote the things.

	<mike
--
All around my hat, I will wear the green willow.		Mike Meyer
And all around my hat, for a twelve-month and a day.	mwm@berkeley.edu
And if anyone should ask me, the reason why I'm wearing it,	ucbvax!mwm
It's all for my true love, who's far far away.		mwm@ucbjade.BITNET