[Courses] [FS] Lesson 2 - Symlinks Question

[Travis Casey]

Monday, July 14, 2003, 10:34:49 AM, Dom Incollingo wrote:

> Hello,

> I really enjoyed lesson 2.  Thanks very much!  But I'm having trouble understanding the ../ directory in the target directory of a symbolic link.

> I created the following directories:

>    /home/dom/tempStuff/testx/sub1/sub2/sub3
>    /home/dom/tempStuff/testy

> When the working directory was set to /home/dom/tempStuff, I executed the
> following command to create a symbolic link:

>    ln -s /home/dom/tempStuff/testx/ testy/

> After I cd'ed into /home/dom/tempStuff/testy/testx, I executed "ls -la .."
> The ls command showed the contents of /home/dom/tempStuff/ - the parent of
> the target. This makes perfect sense so far. (Just as the course explained.)

> But when I execute "cd ..", the working directory becomes
> /home/dom/tempStuff/testy.   Since the ../ directory within
> /home/dom/tempStuff/testy/testx points to /home/dom/tempStuff, I
> would have expected the "cd .." command to change the working
> directory to /home/dom/tempStuff.  What am I misunderstanding?

It varies with different shells.  Some shells actually check the ".."
entry in the directory and take you wherever it points.  Others simply
assume that ".." will always be the directory "above" the current one
in the working path, and don't look at the actual entry.

Which behavior is better?  Well... it depends.  Having ".." go to the
real entry makes logical sense, but it can be confusing in the case of
directories which are linked to somewhere else in the file tree.  For
example, if /usr/adm is a symlink to /var/adm, then using the first
method, doing:

cd /usr/adm
cd ..

will result in being in /var ... which can be confusing to many new
users.  Using the second method, it results in being in /usr, which
makes more "intuitive sense" to many people.

Things can also get fun using the first method when there are symlinks
pointing "shallow" directories to "deep" directories.  For example,
when I was working at FSU's Computer Science department, we had
upwards of 150 Unix workstations, with five different major
architecture/OS combinations.  To keep from spending most of our time
copying things around (and because a lot of the older machines had
very small hard disks), most software was installed under
/usr/local... which was a symlink to a different NFS-mounted
directory, depending on the architecture and OS.

So, doing

cd /usr/local/bin

might actually put you in something like

/home/cs20/systems/sun4x/solaris/usr/local/bin

Someone wanting to go from there to /usr/bin might type

cd ../../bin

but that would error, since /home/cs20/systems/sun4x/solaris/usr/bin
did not exist.  They'd think "WTF?  I know /usr/bin exists!  If it
didn't the system wouldn't work!"  They'd then either start trying to
investigate and (1) realize what was going on, or (2) get enormously
confused, or (3) call or email Systems and report that something's
wrong.

For obvious reasons, we found shells which just "fudged" cd .. to be a
blessing in that environment.


Now, there are a couple of minus sides...

 - cd is a shell internal command, but cp, ls, mv, etc. are not.  As
   far as I know, all of those actually read the ".." entry instead
   of trying to "fudge" things.  I suppose one could write a shell to
   interpret ".." in commands before passing it on, but I don't know
   of any that do, and it seems fraught with possibilities for error.

 - Some crackers have taken advantage of the fact that many shells do
   ignore the ".." entry in directories... by unlinking ".." and
   creating a subdirectory named "..".  This then functions as a
   nicely hidden place to plunk things.  No one's going to look twice
   at ".." -- they're just going to assume that it's what it usually
   is.  Unless someone does an "ls .." or the like, they're never
   going to notice it, unless/until they run a file system check.

   (Some crackers use "...".  A normal "ls" doesn't show dotfiles,
   and in an ls -a, many people will just subconsciously skip the "."
   and ".." entries... and not notice that there's a "..." as well.
   And, of course, a file system check won't complain about "..."
   existing -- it's a strange directory name, but a legal one.)

-- 
Travis Casey
efindel at earthlink.net