On 12/29/2009 11:49 AM, Benjamin Franz wrote:
> John R Pierce wrote:
>> Marko Vojinovic wrote:
>>
>>> You mean new to the concept of files and directories? This is not Linux-only.
>>> The . and .. existed even in MS-DOS back in the 80's.
>>
>> having an actual . and .. file in a directory is a distinctly Unix
>> practice. It leads to some funny behavior too, especially when
>> combined with symlinks
>
> Umm. No. Try launching a 'cmd' shell under Windows (whatever version)
> and doing a 'dir' anywhere except the root directory and you will see
> '.' and '..' entries.
The difference is that on Windows, there aren't really directory entries
in the filesystem called "." and "..". The Windows kernel has special
knowledge that "." means "current directory" and ".." means "previous
directory". The Windows OS kernel is superficially mimicking Unix here,
whereas Linux, like the solid Unix clone that it is, is actually
exposing a literal truth about the underlying filesystem.
On any filesystem designed in the Unix Way, . and .. are actual
directory entries, clear down to the lowest level of the filesystem.
They are special in only two ways. First, they're automatically created
and destroyed as needed by the filesystem driver code to maintain a sane
directory structure. Second, they're hard links, something most Unixy
filesystems don't normally allow with directories due to the potential
for havoc. These are the *only* distinctions these directory entries hold!
Let's do a little playing around to explore this:
$ mkdir foo
$ cd foo
$ ls -ld . | cut -f2 -d' '
If you do this on a Unixy filesystem, you will get '2', meaning that
there are two references to this "foo" directory entry in the
filesystem: one the actual directory entry named "foo" and the other the
"." hard link within that directory which refers to the same directory
entry in the filesystem. Yes, there literally is a "." entry inside the
"foo" directory, referring back to "foo", thus making the reference
count 2, not 1 as you might naively expect. A directory entry with a
reference count of 0 or 1 would mean the filesystem is corrupted, and is
one of the things fsck tries to detect and fix.
If you have a Windows box with Cygwin on it and try the above commands
there, you get '1' instead. Why? Because '.' isn't actually a
directory entry in the NTFS scheme. It's fakery implemented under the
hood to mimic the Unix way of referring to the current directory, not a
real object as on a Unix system.
Still thinking this is just a distinction without a difference? Okay,
try this:
$ cd /
$ ld -ld . | cut -f2 -d' '
I get 28 on one Linux box here. Why 28? Because there happen to be 25
subdirectories off the top-level root on this system, each of which
contain a ".." hard link back to the root, plus one each for "." and
".." in the root directory, and one final one for the actual root
directory entry. 28. Notice how all of the ".."s are real hard links,
each of which increases the reference count of the directory entry it
refers to. It also points out something else that goes back to the tail
end of the text I quoted above, which is that there is a ".." in the
root directory of a Unix file system. It is special only in that it's a
kind of loop-back, pointing to the same directory entry as the "." entry.
Try the above commands on Cygwin and you'll get 1 again, proving that .
and .. are not actual parts of your Windows box's filesystem. They're
superficialities, papering over a great deal of complexity down at the
NTFS implementation level.
This is just one of the many ways Unixy systems are actually simpler,
more transparent, and easier to understand than Windows systems. Both
systems achieve the same end, but Unix does it in a more coherent way,
with fewer concepts and special cases.