Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!mimsy!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: /bin/test and stat(2) Message-ID: <6555@brl-smoke.ARPA> Date: Sun, 11-Oct-87 09:42:45 EDT Article-I.D.: brl-smok.6555 Posted: Sun Oct 11 09:42:45 1987 Date-Received: Mon, 12-Oct-87 23:56:24 EDT References: <9721@brl-adm.ARPA> <1849@munnari.oz> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 90 In article <1849@munnari.oz> kre@munnari.oz (Robert Elz) writes: >"" is NOT ".", they are two totally different names (which happen to usually >be links to the same file). Elz is usually right, but this time he isn't. I've never seen a UNIX implementation where the empty string was an actual link. A link IS an entry in a directory file. Many (all older) implementations have explicit links for "." and ".." in every correctly-formed directory. It is possible, if a directory is somehow corrupted, for either of these structural links to be lost or to acquire the wrong i-number. Back when "mkdir" was done in user mode by the sequence mknod(), link(,"."), link(,"..") (which required superuser privilege in order to plant links to directories), if "mkdir" was interrupted in the middle of the sequence one could get a corrupted directory structure. It's harder for that to happen on newer systems where all the "mkdir" actions are done ("atomically", cough, cough) inside the kernel. By the way, "fsck" can usually fix corrupted "." and ".." links. Some newer implementations, such as perhaps NFS involving an MS/DOS remote system, do not have "." and ".." entries in directories. I understand that at least one H-P UNIX implementation is like this, too. However, such systems can upon request open(".",0), due to special kernel code (in what is usually referred to as the namei() function: name-to-inumber mapper) that "knows" what is meant by ".". (Similarly for "..", but that's not involved in the current discussion.) >"" is the ONLY totally reliable way for a process to access its current >directory, "." searches the current directory file the name "." and >normally finds an inode which is usually the current directory. But >this is not guaranteed. "." IS guaranteed to refer to the current directory, unless your filesystem is corrupted, in which case you should fix it (fsck etc.). >In some kernels, the vendor has decided to hard wire in the "." -> "" >mapping, so that it can't be changed. That's fine, changing the meaning >of "." is not something that intelligent people do (which is probably why >I do it from time to time). These systems are typically not really unix. Well, you're running afoul of POSIX, SVID, and probably every other formal description of the UNIX hierarchical filesystem structure when you deliberately mangle your "." entries. The reason that linking to directories was deliberately restricted to privileged processes was to prevent exactly this sort of structural corruption. >Unfortunately, there are kernels which have prohibited "", and yet which >haven't wired in ".". In these kernels (including one quite famous and >widely distributed version) there is no guaranteed way for a process to >access the current directory. "." is the only advertised way to access the current working directory without keeping track of the path used to get there. Under normal circumstances, there is no way for a normal user process to subvert the advertised meaning of ".". (A privileged (UID==0) process can of course do anything at all, including completely mangling the filesystem or replacing the kernel with an alternative that looks nothing like UNIX.) > As another limiting case, the null file name refers > to the current directory. Yes, this is the explicit mention of "" that I was referring to when I said that it wasn't just an oversight. However, this property is no longer true for many existing implementations. >Logically, to prohibit "" as a name, one would also have to prohibit "/" >as a name, since they are logically equivalent. "/." would be required >to reference the root ... Sorry, I don't see any "logical equivalence". In fact, as you must know, many people are successfully using systems where "" doesn't work but "/" does access the root of the filesystem hierarchy. >It is not a "quirk" regardless of what some people have claimed, its >a deliberate, and necessary, attribute of the unix file naming scheme. It does fit the scheme, and makes sense, but it's by no means "necessary". I remember discussing this business with Dennis Ritchie once, and as I recall, his response was that at first he was quite annoyed at "" being outlawed in System V, but after hearing some of the arguments, he reluctantly granted that that position had some validity. The main argument was that the empty string is invisible when used as a component of a path; although "dir/" (with the null string after /) works fine, "/subdir" (with the null string before the slash) doesn't work right, whereas "./subdir" works fine. This shows that "." is SAFER to use as a directory name than "", since lots of applications will construct path names by taking a directory name and appending / and a subdirectory name. The only time "." would be less safe is if somebody has been deliberately subverting the safeguards intended to guarantee the ".", ".." structural integrity.