OSDev.org

iansjack wrote:I'm not quite sure that I understand your problem. As you say, a directory is referenced by an inode, so just store the inode number in the current directory field.

mariuszp wrote:

iansjack wrote:I'm not quite sure that I understand your problem. As you say, a directory is referenced by an inode, so just store the inode number in the current directory field.

Yes, that's the idea. But now, how do I implement getcwd() ? do I just have to store the name of the directory in the inode, and look up names of all parent directories?

Korona wrote:

Brendan wrote:Don't forget that (because of things like symbolic links) there can be any number of paths to an inode.

POSIX (or any other system I know of) does not support hard links to directories, so the canonical path of a directory can be constructed by following .. links.

Korona wrote:POSIX (or any other system I know of) does not support hard links to directories, so the canonical path of a directory can be constructed by following .. links.

Just store a chain of directory entries that point to the current directory.

Brendan wrote:As far as I know; symbolic links (not hard links) to directories have been a standard part of POSIX for decades.

Brendan wrote:Don't forget that (because of things like symbolic links) there can be any number of paths to an inode. For an example of why that matters; if "/a/foo" is a symbolic link to "/b/bar" and the current working directory is "a", then if you do "chdir("foo/..")" then you should (see note) end up with the current working directory still being "/a" and not changed to "/b".

linguofreak wrote:Unix System V apparently allowed hard links to directories, but only root could create them.

mariuszp wrote:OK but what if /a is a symbolic link to /b/c.

Someone sets the working directory to /a. Now, the current directory is the VFS inode for "/b/c". So, the directory ".." would be "/b"; is this the correct behaviour? Or should ".." still point to "/", in which case I must remember the path that was used to reach this inode?

iansjack wrote:if the current working directory is /a then .. is /. Whether /a is a link to a deeper directory is irrelevant. By storing the cwd as /a you automatically "remember" the path that you used to get to it.

#include <stdio.h>
#include <unistd.h>

int main() {
	chdir("x");
	chdir("..");

	char s[1024];
	getcwd(s, 1024);
	printf("Current directory: %s\n", s);
}

davidv1992 wrote:This post has gotten a bit larger than I had hoped, but I think it is important enough to post it anyway.

It is good to realize that there are two viewpoints as to how to handle .. people are presenting here:

Option 1 (POSIX):
One option is to take the view that .. always points to the same thing, the "canonical" parent of the directory. In this view, the directory structure is a pure tree, and when we follow a symlink, we forget that we ever did that.

This has the advantage that the current position is everything you need to determine what any name, including .., means. Furthermore, if you implement the chdir function, this view conforms to the POSIX standard, which might make porting easier in some cases.

The disadvantage is that this breaks the notion that /a/b/../c/d always equals /a/c/d, which can be counter-intuitive towards users. It is also part of the cause of the admittedly somewhat crazy rules for the shell cd command in the posix standard.

Option 2
The alternative is to take the view that to be in a directory always means to have specified some path from root to that directory. Accessing .. then translates to removing the last element of that path.

This has as an advantage that .. in a larger path will always behave as expected, so specifying /a/b/../c/d always means /a/c/d. Hence, one can always simplify path without worrying that this might actually change their meaning.

However, this scheme also has some disadvantages: First of all, everywhere where you access directories using some form of reference, that reference needs to either point or contain the path used to generate this. This would most likely require some amount of extra storage. Furthermore, you end up with some other strange behaviour: for example, two programs could have a handle to the same point in a directory tree, but which contain different origin paths. In that case, they would get different results when interrogating the properties of what the .. entry in that directory points to.

Further notes
Both options are valid ways of implementing the behaviour of symbolic links. Each has their advantages and disadvantages, and you will need to decide what is most important in your system.

For some example implementations, the linux kernel, or at least the glibc/linux chdir function, behaves according to option 1. In contrast, bash behaviour mostly seems to follow option 2, which it seems to achieve by keeping track of the current working directory internally as well.