OSDev.org

I noticed most filesystems make indestructable directories in every directory named . and .. that point to the current directory and the parent directory, respectively. I was wondering why these are used instead of detecting them in the FS driver when the path is processed. They waste some entries in the directory's table and can mess up programs that traverse all the paths in a drive by making an infinite loop. Is there any disadvantage to having the FS driver detect them and process them in the path string without using the . and .. entries in the directory?

Not as far as I know. The current scheme looks like a cheap Unix solution which has been kept.

The Mobius FAT driver strips these out, so they never appear in directory listings, but the FS layer parses ".." itself.

Sidenote: I never really understood the "why '..'" anyways. I remember I was perfectly OK with AmigaDOS "///" instead of Unix "../../.."...

I like Windows 95's ...\ ....\ etc., to move you two levels up, three levels up, etc. Sadly that never made it into NT.

'..', '//', and '...\' all leave something to wish for for the the end-user. If "only" developers and the OS have to deal with above schemes it's not that big a deal. Out of the three I'd pick the Amiga-style (surprise, surprise), but the real question is whether the FS table needs to have the entries '.' and '..' which would be analogous to a double-linked list.

I'd say no, at the expense of a slightly more complicated FS handler. The handler could e.g. handle a path DirA/DirB/DirC/FileA as a list of elements DirA, DirB, DirC, FileA. Changing the current directory to DirC would set the "current directory list" to DirA, DirB, DirC and the handler can then take commands such as '//' or '..\' to set the current directory to that of two levels above of DirC i.e. DirA.

Is . even needed? It only points to the same directory, which is already available by using a relative path (with no / at the start). Seems redundant to me.

Rune Of Fire wrote: Is . even needed? It only points to the same directory, which is already available by using a relative path (with no / at the start). Seems redundant to me.

How about a program in which u have to know which directory u r working in?(provided u r using a command interpreter and u have a Unix like filesystem). "." can be a huge help here.

Other than that there seems no other huge advantage of just".".

anubis wrote:

Rune Of Fire wrote: Is . even needed? It only points to the same directory, which is already available by using a relative path (with no / at the start). Seems redundant to me.

...

Other than that there seems no other huge advantage of just".".

Oh yes there is, and it lies in the path of security & sys admins. Suppose the OS you're using does NOT allow activating executable files in the current directory if you do not explicitly allow it, by adding . to the path, or by doing ./something

If you did allow that (DOS-ish) and some user made his own ls program, which adds his own account to the sysadmin group and lists the current directory afterwards, and then complained to a real sysadmin that there was a problem listing that directory. The sysadmin would go to the dir, do an ls (his ls), see that it works, claim it was his problem, he'd say he mistyped it or something, and he'd have sysadmin access because of such a design error.

I surely hope no system ever allows such things by default. This is afaik the main reason the . has been invented. I on the other hand, have no idea why it is included in DOS.

As I would understand it, the real reason lies in two of the primary design principles of Unix:

1) It is better use dumb code with smart data than to use smart code with dumb data; and
2) When in doubt, use brute force.

By always including the . and .. directory pointers in the directory path, it ensures that the paths will work right even if the software is buggy, or if later versions of the filesystem software accidently don't account for every instance where the paths need to be kept track of. According to the Unix philosophy, the overhead of the added directory pointers is justified by the reduced code size, and the greater robustness of the solution.

However, as a developer of your own OS, you are not obliged to agree with this approach; certainly copying it blindly just because "that's how it is done" is foolish (doing it for POSIX compliance is another matter, but only if you care if your system is POSIX compliant).

In any case, niether solution really works well once you add symbolic links into the equation: if you follow a link to a directory, should ../ bring you to the directory's actual parent, or back to the directory you began in? The answer depends on the circumnstances. While the obvious, brute force approach is to continue using the .. as always, a user is more often going to want to return to the directory they came from; however, this would present a problem with many application programs and shell scripts, which need to know the real path of a file when traversing the directory tree. Trying to keep track of all the possible backpaths for a directory that is symbolically linked to would seem a general solution, but it would require a more complex means of expressing which directory to back into, and has the affect of turning the directory from a simple heirarchial tree graph to a more complex network graph, possibly cyclical. The added complexity isn't justified for the most part.

anubis wrote: How about a program in which u have to know which directory u r working in?

After decrypting your post by exchanging "u" for "you" and "r" for are (r u l33t, or just plain lazy?), my answer is:

That's what `pwd` is for, isn't it?

in most cases, the use of "." can be restricted to the shell (which already remembers its value through the environment variable $PWD for those who wonders how `pwd` program could work without "." ...)

now, being forced to fork a new process which calls "pwd" everytime you want to know in which directory you are is roughly a bad idea...

also, the $PWD env. variable is available for any program, but it isn't updated to reflect the use of "CHDIR"-like system calls.

Imho, the need for "." and ".." comes from the fact that the way open() will process the file name is POSIX-implied while the existence of environment variables or programs like 'pwd' isn't defined in POSIX ...

Solar wrote:
After decrypting your post by exchanging "u" for "you" and "r" for are (r u l33t, or just plain lazy?), my answer is:

That's what `pwd` is for, isn't it?

Thats 'pwd' 4 sure. :-[