..
Way back when when NTFS was first being designed, the designers of the filesystem had a problem - what should they do with "." and "..". Traditionally, in *nix filesystems (and MS-DOS's FAT filesystem), "." and ".." were two hard links that were created by the mkdir command that included links to the current and parent directory.
For subdirectories, "." and ".." posed no issues at all - NTFS could do exactly what *nix and FAT did - create links to the parent and current directory and be done with it.
But there was a problem with the root. You see, *nix just had a "." in the root, HPFS had "." in the root, but FAT didn't have any special characters in the root.
The NTFS guys decided to treat the root exactly the same as any other directory - the root would have a "." and a "..", both of which linked to the root directory. That way apps that traversed should behave correctly.
When they rolled this out, I raised some issues about appcompat to the NTFS team, and their answer was "Nah, it shouldn't be a problem, after all, the worst thing that can happen is if they traverse ".." through the root - no big deal. And it made their design much cleaner - there was nothing special about the root directory, it was just another directory.
Anyone who's read Raymond's blog knows exactly what happened next :).
Yup, the bugs started coming in. You see, applications that tried to present pretty dialogs for navigation (like the common file dialog) allowed the user to type in ".." into their control (or select the ".." entry). Because they wanted to be helpful, they would also show the full path to the file, so when you clicked on ".." it removed the last path element from the file (so "C:\Users\LarryO\Pictures" would be displayed as "C:\Users\LarryO" in the title of the dialog box). Of course, when you clicked on the ".." entry in the root, they immediately crashed because they tried to navigate through "C:" and couldn't find a \ to back up.
So the NTFS guys had to rethink their plans for the root directory. They probably could have gotten away with having just "." in the root and no "..", but the developers decided to be safe - "If FAT doesn't put entries in the root, we won't." And thus the root directory on NTFS partitions doesn't contain a "." or ".." entry.
This post written with Windows Live Writer.
Edit: Replaced symlinks with hard links.
Comments
Anonymous
September 07, 2006
Immediately thought of a few situations where such a change would lead to an infinite loop, although I question whether anyone has actually written such code.
Anyway, the weirdest part about this all is that running "CD ." works in the root directory on Windows 98 using FAT, even though "CD .." does not.
In Windows XP using NTFS, both "CD ." and "CD .." work in the root. This leads me to believe that both shells have special-casing for "." and ".." for some commands.
I wonder, is it possible to delete the "." and ".." symlinks in any filesystem/operating system? What's to stop something from removing them at a low level? What kind of chaos happens if they are gone? Do disk-checking (chkdisk or fsck) fix these problems?Anonymous
September 07, 2006
Interesting, I never noticed the missing '.' & '..' in the root on NTFS volumes.
"type .autoexec.bat" however still works when you run it from the root. I wonder how that is implemented.
-Anonymous
September 07, 2006
In Unix, . and .. are hard links. Not symbolic links.Anonymous
September 07, 2006
> For subdirectories, "." and ".." posed no issues at all - NTFS
> could do exactly what *nix and FAT did - create symlinks to
> the parent and current directory and be done with it.
In Unix they're hard links, and Unix had "." and ".." before it even had symlinks.
Though the command "cd .." behaves differently in Linux than in every other Unix system I've used, and I always thought Linux's "cd" command was coded specially to do that, but now you make me wonder if Linux has made ".." into symlinks instead.
This is the first I've heard about FAT having symlinks.
Thursday, September 07, 2006 3:55 PM by TheMuuj
> I wonder, is it possible to delete the "." and ".." symlinks in
> any filesystem/operating system?
Considering that they were (and usually if not always still are) hard links, think of what might happen when "rm -r" gets to "..". My understanding is that the "rm" command got some extra coding added to it very quickly, maybe when only around 3 people had ever heard of Unix ^_^Anonymous
September 07, 2006
You're right Clinton.
Norman, they were special symlinks - exactly the same as they were implemented on *nix - the root FAT index on the parent drive simply was the FAT index of the parent and similarly the . pointed to itself. chkdsk knew about these entries and knew how to verify them.
For RM, it had special code to bypass . and .. So did a bunch of "tree walking" utilities.Anonymous
September 07, 2006
To understand about hard links in UNIX you need to understand a little bit about how directories and inodes are associated with each other.
A directory in it's most simplest form is a list of inode numbers and file names.
An inode can have an entry in more than one directory. These are called "hard links". For each one of these a link count in the inode is incremented.
Now, if we have a look at the root of the directory tree (here's where Unix differs as it uses a single rooted tree as against a rooted tree per drive), we see that the entries for '.' and '..' are pointers to the same inode (for historical reasons this happens to be inode 2).
The filesystem has no concept of orignal and linked copy. Both entries are references to the same inode.
As both '.' and '..' point at the same inode, doing a cd to either leaves you at the root of the tree.
Things get a little more complex when you mount other filesystems into the tree. Basically, the act of doing the mount replaces the lookup of the directory on which the filesystem is mounted with inode 2 of the mounted filesystem and the lookup of '..' in this filesystem is replaced with a lookup to the parent of the directory it is mounted on. This is probably beyond the scope of what we are talking about here. :)
This way, the behaviour o faccessing directories through '.' and '..' on Unix remains predictable.
alan.Anonymous
September 07, 2006
Thanks Alan.
That's essentially what happens in FAT and NTFS as well - they're not inodes obviously, but logically it's a similar situation - for FAT, it's the index of the starting cluster in the FAT, for NTFS it's something else (I don't exactly know what).Anonymous
September 07, 2006
The comment has been removedAnonymous
September 08, 2006
This is not a comment related to the subject of your post.
In this post I saw that you have prepared this using Windows Live Writer!!!. Is it working fine for you? I'm always getting an error. Are you using Proxy server for connection?
This was the error I got:
"Error attempting to connect to weblog at:
http://sarathc.wordpress.com/xmlrpc.php
The underlying connection was closed: A connection that was expected to be kept alive was closed by the server."Anonymous
September 08, 2006
The comment has been removedAnonymous
September 08, 2006
KJK::Hyperion:
RE: Special environment varaible "where the environment variable %=X:% contains the working directory for drive X: "
These actually seem to be X:= variables, and do not have a name.
I've just dumped all of my environment variables, and what I actually see (on XP) is that there are several unnamed environment variables whose values are, e.g., "C:=C:temp" and "D:=D:testvideo". Interestingly, these are only created by actually visiting a disk; until I actually set my current disk to "X:" I didn't get an "X:=..." variable.
Other unnamed variables include one with the value ::=:: and, after a program runs, an "ExitCode=00000000" value.
Does anyone know of a 'canonical' list of possible unnamed environment variables?Anonymous
September 08, 2006
I'm 99.999% sure that in Windows 9x if you were in C:dir1dir2, you could go dir ... and it would show you the contents of C:. Similarly, if you were in C:dir1dir2dir3, you could go dir .... and get the same thing, ad infinitum. Don't have a machine to try it on, though.
Now I try it on Win 2k, dir ... in C:dir1dir2 gives you the contents of C:dir1dir2.. while dir .. gives you C:dir1 - i.e. same listing, different header, so it looks like the shell is doing something here. And dir .... doesn't work at all.
Anyone know how to search for "..." on Google????Anonymous
September 08, 2006
i always wondered why cd ... didn't move up by two directories, and so on.
the idea of having a "cd .........................."
command seemed fun (when i was about ten years old, anyway...)Anonymous
September 08, 2006
But I'm still curious, if "." and ".." exist physically on the drive, via hardlinks or whatever method, what happens if they get removed. I realize that none of the shell commands will let you do this (hopefully), but what if somebody went in with a low-level disk editor and deleted the entries? Would this cause endless problems? Or do most operating systems special-case "." and ".." these days so they work even without something on the disk?Anonymous
September 09, 2006
The comment has been removedAnonymous
September 10, 2006
The comment has been removedAnonymous
September 10, 2006
@Sarath: I've found that Windows Live Writer works great with Community Server (which is what blogs.msdn.com runs under) but is "flakey" with anything else.Anonymous
September 11, 2006
The comment has been removedAnonymous
September 15, 2006
About "cd" on bash: you can use "cd -P" to follow the physical structure, or "cd -L" to follow the "logical" structure. You can also use "set -P" or "set +P" to change the default.
About low-level disk editing: at least on ext2, "." and ".." do exist on the disk and are created by fsck if missing.Anonymous
May 31, 2009
PingBack from http://indoorgrillsrecipes.info/story.php?id=4344Anonymous
June 08, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=5547Anonymous
June 09, 2009
PingBack from http://greenteafatburner.info/story.php?id=486