peter@sugar.UUCP (09/30/87)
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*.
mwm@eris.UUCP (10/01/87)
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
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/01/87)
The parent directory is '/', the device base (root) is ':', the current directory is "" (NULL). Let's take a look at this. The only thing I don't like about the format is the "" for the current directory.... one should not use 'special' non-ascii cases for file/directory naming. The only thing I find missing is that there is no 'super-root' which contains all the devices. However, I *like* to use '/' to mean the parent directory (never did like ..). And like it or not C-A (Rightly) is not about to completely throw away the current naming conventions. So why don't we extend the format as follows: '.' means current directory as well as '' have a super-device called ROOT: which simulates a directory containing ALL the devices in the system (including ROOT:) AND all the ASSIGN names. For instance, there would be an entry in ROOT: named 'DF0:'. The parent directory of any device BASE would be ROOT: -Matt
ford@crash.CTS.COM (Michael Ditto) (10/04/87)
In article <837@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > [ ... ] 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. Just a note: a null string is not a legal filename on Unix System V; attempting to open() or otherwise access it results in an ENOENT error. -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu