FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 12-29-2009, 08:06 PM
Bob McConnell
 
Default mkdir this "." directory

Marko Vojinovic wrote:
> On Tuesday 29 December 2009 18:21:01 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.
>
> I was not trying to say that . and .. were *invented* in MS-DOS. I was just
> commenting that it is not Linux-specific (or Unix-specific). The point was that
> a newbie would encounter . and .. equally well on both Linux and Windows
> systems. The only difference is that Windows does not encourage the use of a
> terminal, unlike Linux. Therefore, the fact that someone is confused by the
> existence of . in some directory is mainly the fault of GUI-for-everything
> philosophy of Windows.

MS-DOS 2.0 added subdirectories, I/O redirection, pipes, filters and a
few other features copied from Unix. Of course they were mere shadows of
the actual Unix features and lacked most of the standard capabilities,
but it was a step in the right direction. It is one of the few steps in
that direction Microsoft ever took.

Bob McConnell
N2SPP
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-29-2009, 08:08 PM
Stephen Harris
 
Default mkdir this "." directory

On Tue, Dec 29, 2009 at 04:06:09PM -0500, Bob McConnell wrote:
> MS-DOS 2.0 added subdirectories, I/O redirection, pipes, filters and a

Ah, pipes... yeah, that was a fun implementation. Because DOS was single
tasking the pipe actually wrote the data out to a temporary file, then
when the generating program finished the consumer program would be started
up to read from the temporary file.

Slow as hell on floppies! And you'd better hope you had enough free space
on the disk :-)

--

rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-29-2009, 08:11 PM
Warren Young
 
Default mkdir this "." directory

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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-29-2009, 08:18 PM
 
Default mkdir this "." directory

> Marko Vojinovic wrote:
>> On Tuesday 29 December 2009 18:21:01 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.
>>
>> I was not trying to say that . and .. were *invented* in MS-DOS. I was
>> just commenting that it is not Linux-specific (or Unix-specific).
<snip>
>> terminal, unlike Linux. Therefore, the fact that someone is confused by
>> the existence of . in some directory is mainly the fault of
>> GUI-for-everything philosophy of Windows.

And Macs. I agree. To quote a friend, "your momma dresses you funny, and
you need a mouse to delete files!"
>
> MS-DOS 2.0 added subdirectories, I/O redirection, pipes, filters and a
> few other features copied from Unix. Of course they were mere shadows of
> the actual Unix features and lacked most of the standard capabilities,
> but it was a step in the right direction. It is one of the few steps in
> that direction Microsoft ever took.

Yeah, and 3.0 broke a number of things that were in 1.0 and 2.0; one of
the biggest mistakes M$ ever made was not introducing in 3.0 at least
foreground/background multitasking (you couldn't print and do anything
else!) and virtual memory. If they'd done that then, WinDoze wouldn't have
been the disaster it became with the 95 line.

mark "the other, of course was putting the GUI in ring 0"

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org