Are the ‘dot’ and ‘dot dot’ files in Unix and Linux real files?

Question

Do the special files . and .. actually exist and are stored/located in the file system as normal files, or are they interpreted/created only when a

Answer 1

You are correct in your assumption. These files are merely there as an abstraction layer to navigate to and describe a resources location..

Answer 2

I don't think the currently accepted answer is correct, or at least it's not clear what it really means.

"." and ".." are most definitely "real". In that any directory has a real entry for "." (pointing to the directory's own inode), and a real entry for ".." (pointing to the inode of the directory's parent directory). These are actual entries in the directory, so they are "real" in that sense. There aren't separately allocated inodes with duplicate data in them, if that is the intent of the original question.

The original poster said, "My assumption is that they do not exist – otherwise, when you create symlinks or bind mounts, things would break" - I'm not sure what is referred to here, except I can take a guess about what is meant by symlinks breaking - I imagine this refers to the case of a symlink that points to a directory, and then when you "cd" through the symlink, where does ".." end up? In other words, if you have a symlink at "/a/b/c" that links to a directory called "/x/y/z", and you do "cd /a/b/c", where would you end up if you then did "cd .."? The answer is, where you end up is "/x/y" - and the only reason that is confusing is that modern shells "know" when you have done a "cd" through a symlink, and they will assume you want ".." to refer to the parent of where the symlink is, rather than where it points to. IMHO, this is totally broken behavior and no one should have ever implemented this... But to see what I mean, in a shell like "bash", if you were to create a scenario like I described above, and cd to "/a/b", run "pwd" and you'll see your current directory as you expect. If you then "cd c", and run "pwd", you'll see your current directory as "/a/b/c" - but if you run "/bin/pwd" (the external "pwd" program rather than the shell builtin), it tells you the truth and says "/x/y/z". Likewise, if you would then do "cd ..", you end up back in "/a/b", even though the real ".." entry where you are ends up in "/x/y", to make the semantics of changing directories more what people "expect" - because the shell "knows" you got where you were through a symlink, and it assumes that you want ".." to end up back where you started, rather than the true parent directory if your current directory... As I said, IMHO, this is totally broken behavior, and really serves to confuse people when they are thinking about what "." and ".." actually mean.