./

[invalid at pizzashack.org (Derek Martin)]

On Mon, Nov 10, 2003 at 05:31:39PM -0500, Chris Devers wrote:
> On Mon, 10 Nov 2003, eric wrote:
> 
> > hey. it's not easy teaching yourself linux.  here's one for somebody
> > who's bored tonight...  what does ./ mean?
> > if i cd to /usr/sbin and then type tripwire, nothing happens, but if i
> > type ./tripwire off we go.  why?
> 
> It's a path hint. In most/all Unix filesystems -- as well as DOS/FAT --
> '.' is shorthand for the current directory, and '..' is shorthand for the
> directory one level up from the current directory. As a parallel, '~' is
> shorthand for your home dir.
> 
> So, when you type "./foo", the shell expands that "." to whatever the
> current working directory is. If you're in /usr/local/bin, then that is
> what '.' would expand to.

Factually, this is not exactly right.  In reality, every directory
contains an entry "." which is a hard link to itself.  This is not a
shorthand notation, nor something the shell expands.  "." is a real
directory entry that exists inside every directory.  You will see it
if you use the -a option to ls.  If you also use the -i option, you'll
also be given the inode number:

  $ pwd
  /home/ddm
  $ ls -lid .
    29313 drwx--x--x   27 ddm      ddm          4096 11? 11 14:13 ./
  $ cd ..
  $ ls -lid ddm
    29313 drwx--x--x   27 ddm      ddm          4096 11? 11 14:13 ddm/

You will note that the inode (the first field) in both cases is 29313.
This is because /home/ddm and /home/ddm/. are both real directory
entries which point to the same inode, in this case the inode for the
directory /home/ddm.

Every subdirectory of that directory also contains an additional hard
link to that directory.  If you look in the 3rd field of the ls output
above, you'll see the number 27.  This is the link count of that file
(inode).  There are 27 directory entries which all point to that same
inode.  One is /home/ddm, the second is /home/ddm/., and the other 25
are the ".." entries in the 25 subdirectories in my home directory.
The ".." is also not shell shorthand... they are real directory
entries that exist in the filesystem.  A file exists on the Unix
filesystem until its link count is zero.

You can play with this using regular files.  [Note that hard links
must be created on the same filesystem as the file originally was
created.]

  $ touch testfile
  $ ls -li testfile
    44057 -rw-r--r--    1 ddm      ddm             0 11? 11 14:38 testfile

Here, we've created testfile, with inode #44057.  Note the link count
is 1 (third field).  Now we will create a subdirectory called testdir,
and create a hard link to testfile in that directory.  To create a
hard link, use the link command without the -s option (which would
create a symbolic link, rather than a hard link).

  $ mkdir testdir
  $ cd testdir
  $ link ../testfile testlink
  $ ls -lia
  total 8
    14683 drwxr-xr-x    2 ddm      ddm          4096 11? 11 14:38 ./
    43987 drwxr-xr-x    4 ddm      ddm          4096 11? 11 14:38 ../
    44057 -rw-r--r--    2 ddm      ddm             0 11? 11 14:38 testlink

Note that testlink has the same inode number as testfile.  This is
because it is the same phyiscal file.  Note also that the link count
is 2.  If you look at the original file, the link count will also now
be 2:

  $ cd ..
  $ ls -liad test*
    14683 drwxr-xr-x    2 ddm      ddm          4096 11? 11 14:38 testdir/
    44057 -rw-r--r--    2 ddm      ddm             0 11? 11 14:38 testfile

Next, we can delete the original file, testfile.

  $ rm testfile
  $ ls -liad test*
    14683 drwxr-xr-x    2 ddm      ddm          4096 11? 11 14:38 testdir/

The file is deleted.  But it isn't, really:

  $ cd testdir
  $ ls -lia
  total 8
    14683 drwxr-xr-x    2 ddm      ddm          4096 11? 11 14:38 ./
    43987 drwxr-xr-x    4 ddm      ddm          4096 11? 11 14:39 ../
    44057 -rw-r--r--    1 ddm      ddm             0 11? 11 14:38 testlink

Note the link count is now 1, because we deleted the original file.
Or, to say that correctly, we unlinked the first hard link to the file
which was created...  

Unlike if you had created a symbolic link, you can still access the
contents of the file (if it had any).  Now, we'll really delete the file.

  $ rm testlink
  $ ls -lia
  total 8
    14683 drwxr-xr-x    2 ddm      ddm          4096 11? 11 14:43 ./
    43987 drwxr-xr-x    4 ddm      ddm          4096 11? 11 14:39 ../

Of course, there may have been more links to the file, in which case
the link count would have been higher. There is no way to verify that
the file is really deleted without using the find command to locate
the file with that inode.  If it comes back with no results, then you
know the file is really gone.

If we recreate our test links as above, find will reveal them:

  $ find . -inum 44057
  ./tmp/testfile
  ./tmp/testdir/testlink

CAVEAT: find (or at least some versions of it) ignores "." and ".."
entries when you feed it the inode of a directory.  So you can't find
those entries that way, but they're managed by the operating system,
so this shouldn't ever be an issue.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.
Replying to it will result in undeliverable mail.
Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20031111/3616332c/attachment.sig>