[CentOS] mkdir this "." directory

[Warren Young]

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.