-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Larry Brower Sent: Monday, December 28, 2009 18:58 To: CentOS mailing list Subject: Re: [CentOS] mkdir this "." directory

adrian kok wrote:

...

Hi

I have this . folder under tmp

1/ How they can make it this folder?

Please provide the output of ls -la /tmp

Are you referring to ./ or actually something like \./ ?

Either would not show up as a single .

...

2/ How can I remove it?

If it is really ./ then you dont as this is /tmp If it is \./ then rm -vr /tmp/\.

...

Thank you

Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.

On 12/29/09 1:41 PM, Mike A. Harris wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

adrian kok wrote:

...

Hi

I have this . folder under tmp

1/ How they can make it this folder?

2/ How can I remove it?

Thanks, I just about spit my coffee out my nose when I read this, but it made my day. :)

Last day of vacation :D . http://dban.sf.net is recommended for removing "." directories from harddisks..

-- Eero, RHCE

On Tuesday 29 December 2009 14:46:23 Anne Wilson wrote:

On Tuesday 29 December 2009 13:59:43 Ugo Bellavance wrote:

...

On 2009-12-28 18:49, adrian kok wrote:

...

Hi

I have this . folder under tmp

It is a system-generated link to the current directory. Don't touch that.

Thank heavens there's one sane person reading today. Obviously no-one else here was ever new to Linux.

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. And they still exist, actually. The problem is that today people working under Windows [7|Vista|XP] never get to open a terminal anymore, and various GUI's play smart with them and don't show the links to current and parent directories.

Best, :-) Marko

Timo Schoeler wrote:

Marko Vojinovic wrote:

...

On Tuesday 29 December 2009 14:46:23 Anne Wilson wrote:

...

On Tuesday 29 December 2009 13:59:43 Ugo Bellavance wrote:

...

On 2009-12-28 18:49, adrian kok wrote:

...

Hi

I have this . folder under tmp

It is a system-generated link to the current directory. Don't touch that.

Thank heavens there's one sane person reading today. Obviously no-one else here was ever new to Linux.

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. And they still exist, actually. The problem is that today people working under Windows [7|Vista|XP] never get to open a terminal anymore, and various GUI's play smart with them and don't show the links to current and parent directories.

Sure, but: Nobody's guilty *not* to have seen this stuff in her/his whole life just because she/he never looked at it. There may be multiple reasons for that, one of them may be a simple 'I was born in 1996 and never had the chance to work with CP/M'. ;)

Never say "never". You still have the opportunity to work with CP/M, either with custom built hardware or any of a number of good simulators currently available on Source Forge. There is still an active Usenet newsgroup on the topic (comp.os.cpm), with hardware being designed and new kits being sold. Almost all of the source code is now available at http://www.cpm.z80.de/.

Bob McConnell N2SPP

Marko Vojinovic wrote:

...

On Tuesday 29 December 2009 14:46:23 Anne Wilson wrote:

...

On Tuesday 29 December 2009 13:59:43 Ugo Bellavance wrote:

...

On 2009-12-28 18:49, adrian kok wrote:

...

I have this . folder under tmp

It is a system-generated link to the current directory. Don't touch that.

Thank heavens there's one sane person reading today. Obviously no-one else here was ever new to Linux.

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. And they still exist, actually. The problem is that today people working under Windows [7|Vista|XP] never get to open a terminal anymore, and various GUI's play smart with them and don't show the links to current and parent directories.

Sure, but: Nobody's guilty *not* to have seen this stuff in her/his whole life just because she/he never looked at it. There may be multiple reasons for that, one of them may be a simple 'I was born in 1996 and never had the chance to work with CP/M'. ;)

On the other hand, someone *is* guilty if they pick up something new, and DON'T BOTHER TO RTFM, even cursorily.

mark

On Tue, Dec 29, 2009 at 10:21:01AM -0800, John R Pierce wrote:

for instance, say /home/pierce is a symlink to /home2/pierce and I'm in /home and go cd pierce, then go cd .. in *some* unix systems, that cd .. takes me back to home, in others takes me to /home2

It's actually shell dependent, not Unix platform dependent. Some shells (eg bash, ksh) perform parsing of the "cd" parameter and so will appear to back-out of symlinks. Other (typically older) shells just naively do a chdir("..") call, which will take you to the real parent directory.

Sometimes both behaviours are useful, so I've created a function "up"

up() { cd "`/bin/pwd`/.." }

So...

/home/sweh$ cd public_html /home/sweh/public_html$ cd .. /home/sweh$ cd public_html /home/sweh/public_html$ up /autofs/publish$ ls -l /home/sweh/public_html lrwxrwxrwx 1 sweh sweh 20 Jun 8 2008 /home/sweh/public_html -> /autofs/publish/public_html/

Symlinks combined with automounters... fun :-)

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.

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

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"