Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!nysernic!itsgw!batcomputer!cornell!uw-beaver!mit-eddie!husc6!necntc!ames!lll-tis!lll-lcc!lll-winken!uunet!nuchat!sugar!peter
From: peter@sugar.UUCP
Newsgroups: comp.sys.amiga
Subject: File naming conventions.
Message-ID: <837@sugar.UUCP>
Date: Wed, 30-Sep-87 08:37:14 EDT
Article-I.D.: sugar.837
Posted: Wed Sep 30 08:37:14 1987
Date-Received: Sat, 3-Oct-87 06:16:13 EDT
References: <503@louie.udel.EDU> <1929@umd5.umd.edu> <775@sugar.UUCP> <5218@jade.BERKELEY.EDU>
Organization: Sugar Land UNIX - Houston, TX
Lines: 223

In article <5218@jade.BERKELEY.EDU>, Mike Meyer writes:
> Ah SO! The light dawns. Peter and I have different interpretations of
> the Unix file name semantics. He says that "null is a kludge, as it
> means the current directory everywhere but the beginning of a path
> name." I says "/ is a kludge, as it means look in the current
> directory for the following file name everywhere but the beginning of
> the file name." This explains the differences in the table, and some
> other things.

Still haven't got it right. I said that NULL is not a valid filename on UNIX
in all contexts. It's nice that NULL maps to the current directory. It's even
useful in some contexts. I would definitely NOT advocate making it illegal.
I'm just saying that it's not the canonical name for the current directory.
"." is.

> Note that we agree on the semantics, but disagree on how they should
> be interpreted. Peter's way leads to a nicer system ("/file" appended
> to a directory name always means find "file" in the directory); mine
> is modelled after the source code.

I've never seen the source code to UNIX (I know, how did I go through Berkeley
without hacking it :->), so I seem to have avoided confusing the semantics
of the file system with the implementation.

> That this double interpretation can happen at all is a sign that
> something is fundamentally broken in the Unix file name mapping.

You're the first person I've run across who's made this particular
interpretation.

> Possibly it's that a null directory name isn't an error.

No, because then you couldn't use "/" as root. You'd have the same problem
as AmigaDOS. You'd have to do something like 

	find /. -name core -exec rm '{}' ';'

which is icky.

Actually, the problem is that if you start looking at the semantics, NULL
in AmigaDOS means "the parent directory". If you make this interpretation,
then you can always add a slash and get a filename. Totally consistant,
except that now there's no name for the current directory. It happens that
if you provide a null most of the standard DOS programs will interpret it
as the current directory. Not all, of course, which is why I kept getting
popped up one level.

Oh yes, and now you don't have a name for the root that can have a "/" tacked
on to it.

Mixed semantics.

My feeling is that NULL should not have to be used as a name. It's nice if
it does something innocuous (like leaving you in the same place) if you
want to use it, but that's not necessary. There should, therefore, be a name
that you can use for anything you want to refer to. UNIX uses "." and ".."
for the current and parent directories. The Amiga doesn't really have a name
for these objects.

> <> 	either a file in dir, or a file in the root directory if dir
> <> 	is null.
> <
> <I don't think that you would ever be using null as the name of the current
> <directory unless you have a bug somewhere.

When I say bug I mean bug. Somewhere your program has lost a name and is
flailing around trying to come up with something.

> Same logic applies to AmigaDOS, so you should be able to drop it's
> version to be the same as the Unix version. In fact, that logic is
> even stronger in AmigaDOS, because a "null" directory name isn't
> innocuous.

Because NULL means PARENT.

OK. Let's forget about adding "/filename" and just add "filename".
Say ": is the root, / is the parent, NULL is current, and foo/ is a
subdirectory".

Fine and dandy, and should work with most programs. Except that's not
what the book says, so your programs still have to check for people handing
you foo for a directory name.

> I.e., the accident (your word) of null directories working
> the way they do make this work.

When did I use "accident" for this? Quotes, please. I think that perhaps
you're misinterpreting me.

> <In AmigaDOS you have to parse the name, and
> <if the name is the current directory or the root you don't put the slash in.
> <The parsing is trivial in 'C', but I'd hate to try to do it in a shell
> <script. And a number of programs don't parse it right.
> 
> But if you use the "null" current directory in Unix, it breaks also!

But why would you do this? Look at it from a users standpoint. They're told
that dot is the current directory, and / is the root. No mention of NULL
anywhere. NULL is interpreted the way it is because it's the most harmless
interpretation you can make. It means "nothing", "don't move".

> That half the problem is fixed by providing a real name for the
> current directory. Or at least as fixed as it is for Unix.

True. But what about the root?

> Someone suggested ";" as a good name for the current directory. Bad
> move, as that's the start comment character in the CLI. Given the rest
> of the system, I'd be tempted to suggest backslash. But the Unixphiles
> will probably want ".". No problems with it, it's just that it's used
> in file names a lot already.

It is in UNIX, too. The only file names that begin with "." in AmigaDOS
are special ones that the user's not interested in anyway. Like, .info,
.zing, .fastdir, ...

> <Also, why do you say "../" is the real name of the parent directory?
> 
> Because the Amiga DOS parent is "/", and you can just add the file
> name to it. I was trying to make the Unix & AmigaDOS columns have the
> same semantics - at least where possible.

But they don't have the same semantics. In UNIX you add "/name", in AmigaDOS
you add "name" (but you have to be prepared to add "/name" as well).

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

> In other words, you then translate the problem from "Is this the root
> of the device" to "is this the root of a device that handles null
> first components correctly"? The first is trivial to find out; the
> second can change on you between accesses of the same file name.

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

> <NULL is a bad name for the current directory....
> 
> I agree. But once you turn that off, being able to append "/file" to
> directory names to get valid file names quits working for Unix. Works
> exactly the same for AmigaDOS, though.

So who said you should turn it off? I certainly didn't.

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. foo is a file in the current directory.
foo/ is a subdirectory of the current directory, mapped (implementation) into
the file named foo. To take a directory name and get at a file in that
directory you just append the name to it. This is the most consistent
interpretation of AmigaDOS I've been able to come up with.

Unfortunately the documentation and programs treat foo and foo/ the same
(even appending the / to make it a directory name when needed). This means
your programs have to be able to make this fix. Some do it right, some do
it wrong. Thus, NULL may refer to the current directory, or it may refer to
the parent. I've even had it rejected by programs that don't parse "" on the
command line properly.

[ENTER blue-sky mode]

> <That's another thing... since we're changing things around why not switch
> <to conventional directories with the file names in them?

> <I realise there are a few programs that should break... but most of them seem
> <to be fast-directory-listers that were writtent to take care of the warts
> <in the current system. If you were doing this you would need to write and
> <distribute an alternative to disksalv, of course.
> 
> To drag in the LEOS file system discussion, the *reason* that most
> things wouldn't break is because the details of what directories look
> like are hidden by Examine/ExNext. Unless you think you're IBM, and
> know exactly what directory features users want, you should encourage
> people to use ExNext/Examine for any future file system.

Right. I never suggested doing otherwise. The problem is that "getting the
names of files in the current directory" is a very common task, and it should
be quick. 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.

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. 

[EXIT blue-sky mode]

> [On the DEV: device.]
> 
> My fault - I misread what you wanted it to do. Now that I understand
> it, I like it. Gee, just think what
> 
> 	dir dev: opt a
> 
> could do for you. Especially if you've got locks on a dozen disks
> still floating around....

Any of you Lattice people feel up to this?

[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?

[EXIT gritch mode]

[ENTER signature mode]
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.