rcd@opus.UUCP (Dick Dunn) (08/29/84)
I've found (somewhat to my dismay) that there's a difference in filename
handling between the 4.2 BSD and System III lineage. In the AT&T systems,
a null filename (presented to open, access, etc.) behaves as the name of a
nonexistent file. In the Berkeley system, it behaves as the name of the
current directory (i.e., the same as "."). I don't know just when the
change occurred, tho it seems to me that V7 handled it as System III does.
Does anyone know when the split happened, and more to the point, why? I'm
particularly curious as to what the use is for having the null name
reference the current directory. I seem to fall into it periodically, and
the consequences of opening the current directory (which is usually at
least readable) instead of an expected data file are only occasionally
amusing.
--
Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086
...I'm not cynical - just experienced.gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/29/84)
I believe that AT&T fixed the System III null-path-component behavior with System V but am not sure (no System V kernels around here).
rcd@opus.UUCP (Dick Dunn) (08/31/84)
Since posting my original query, I've been corrected--V7 and older systems
treat a null file name as the current directory; Sys III treats it as a
nonexistent file. But I'm still curious about the reason for "" meaning
the current directory.
--
Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086
...I'm not cynical - just experienced.markb@sdcrdcf.UUCP (Mark Biggar) (09/04/84)
In article <opus.772> rcd@opus.UUCP (Dick Dunn) writes: >Since posting my original query, I've been corrected--V7 and older systems >treat a null file name as the current directory; Sys III treats it as a >nonexistent file. But I'm still curious about the reason for "" meaning >the current directory. I don't imagine that it was planned on, it kind of just happened. The code in the file system name resolution routine probably goes: if name starts with slash then use root directory else use current directory endif while not end of string if current file not directory then error get and skip over next name find in current file use it as current file endwhile Note that this resolves "/" to the right thing, but has the side effect of resolving "" to the current directory. This is also explains why things like "cd /usr/spool/" work on v7 & 4bsd and not on system III. Mark Biggar {allegra,burdvax,cbosgd,hplabs,ihnp4,akgua,sdcsvax}!sdcrdcf!markb
henry@utzoo.UUCP (Henry Spencer) (09/08/84)
> I believe that AT&T fixed the System III null-path-component behavior > with System V but am not sure (no System V kernels around here). Nope, the make-null-path-illegal code is present in the System V kernel; we have the sources online even though we don't run it. Dunno about Vr2, we aren't licensed for it yet. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
guy@rlgvax.UUCP (Guy Harris) (09/11/84)
> I believe that AT&T fixed the System III null-path-component behavior > with System V but am not sure (no System V kernels around here). Answering this question, and the original question of "why are null strings handled the way they are?": The reason that a null string referred to the current directory in V7 (and possibly in earlier systems) is that it happened to work that way. No more, no less. System III and System V Release 2 (the only ones I checked; S5 may do it also) have an explicit check for a null pathname and have it return ENOENT. 4.2BSD, and some other systems, go in the opposite direction; they changed the flow through "namei" so as to make it no longer work "that way" - i.e., a null pathname no longer referred to ".". So they put in code to explicitly make a null string refer to ".". I think this is a mistake, and that System N does it correctly, for the same reason I think UNIX systems should keep location 0 out of processes' address space if at all possible; it catches mistakes early. (One of our programs ran in full-screen mode and turned off public write permission on the user's tty ("mesg n") by changing the mode to rw-------; however, sometimes the pathname of the tty would be a null string (or a null pointer which points to a null string on a VAX by pure happenstance; see previous comments on location 0), and the current directory would have its execute permission removed, with rather nasty consequences if it happened to be the user's home directory.) Guy Harris (back from vacation) {seismo,ihnp4,allegra}!rlgvax!guy
henry@utzoo.UUCP (Henry Spencer) (09/12/84)
Friends of mine report that the null pathname is indeed illegal in
System Vr2, and will continue to be so in Vr3.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry