ch13_03.htm

by Randal L. Schwartz and Tom Phoenix ISBN 0-596-00132-0 Third Edition, published July 2001. (See

<p>There's another rule about the links in directory listings: the
inode numbers in a given directory listing all refer to inodes on
that same mounted volume.<a href="#FOOTNOTE-292">[292]</a> This rule ensures
that if the physical medium (the diskette, perhaps) is moved to
another machine, all of the directories stick together with their
files. That's why you can use <tt class="literal">rename</tt> to move
a file from one directory to another, but only if both directories
are on the same filesystem (mounted volume). If they were on
different disks, the inode's data would have to be relocated,
which is too complex an operation for a simple system call.
</p><blockquote class="footnote"> <a name="FOOTNOTE-292" /><p>[292]The one exception is the
special <tt class="literal">..</tt> entry in the volume's
<em class="emphasis">root</em> directory, which refers to the directory in
which that volume is mounted. </p> </blockquote>

<p>And yet another restriction on links is that they can't make
new names for directories. That's because the directories are
arranged in a hierarchy. If you were able to change that, utility
programs like <i class="command">find</i> and <i class="command">pwd</i>
could easily become lost trying to find their way around the
filesystem.
</p>

<p>So, links can't be added to directories, and they can't
cross from one mounted volume to another. Fortunately, there's
a way to get around these restrictions on links, by using a new and
different kind of link: a <em class="firstterm">symbolic
link</em><a name="INDEX-900" /> <a name="INDEX-901" />.<a href="#FOOTNOTE-293">[293]</a> A
symbolic link (also called a <em class="firstterm">soft
link</em><a name="INDEX-902" />
<a name="INDEX-903" /> to distinguish it from the
true or <em class="firstterm">hard links</em><a name="INDEX-904" /> <a name="INDEX-905" /> that
we've been talking about up to now) is a special entry in a
directory that tells the system to look elsewhere. Let's say
that Barney (working in the same directory of poems as before)
creates a symbolic link with Perl's
<tt class="literal">symlink</tt><a name="INDEX-906" /> function, like this:
</p><blockquote class="footnote"> <a name="FOOTNOTE-293" /><p>[293]Some
veryold Unix systems don't support
symlinks, but those are pretty rare nowadays.</p> </blockquote>

<blockquote><pre class="code">symlink "dodgson", "carroll"
  or warn "can't symlink dodgson to carroll: $!";</pre></blockquote>

<p>This is similar to what would happen if Barney used the command
"<i class="command">ln -s dodgson carroll</i>" from the
shell. <a href="ch13_03.htm#lperl3-CHP-13-FIG-3">Figure 13-3</a> shows a picture of the result,
including the poem in inode 7033.
</p>

<a name="lperl3-CHP-13-FIG-3" /><div class="figure"><img height="146" alt="Figure 13-3" src="figs/lrnp_1303.gif" width="318" /></div><h4 class="objtitle">Figure 13-3. A symlink to inode 7033</h4>

<p>Now if Barney chooses to read
<em class="filename">/home/barney/poems/carroll</em>, he gets the same
data as if he had opened
<em class="filename">/home/barney/poems/dodgson</em>, because the system
follows the symbolic link automatically. But that new name
isn't the "real" name of the file, because (as you
can see in the diagram) the link count on inode 7033 is still just
one. That's because the symbolic link simply tells the system,
"If you got here looking for <em class="filename">carroll</em>, now
you want to go off to find something called
<em class="filename">dodgson</em> instead."
</p>

<p>A symbolic link can freely cross mounted filesystems or provide a new
name for a directory, unlike a hard link. In fact, a symbolic link
could point to any filename, one in this directory or in another
one -- or even to a file that doesn't exist! But that also
means that a soft link can't keep data from being lost as a
hard link can, since the symlink doesn't contribute to the link
count. If Barney were to delete <em class="filename">dodgson</em>, the
system would no longer be able to follow the soft link.<a href="#FOOTNOTE-294">[294]</a> Even though there would still
be an entry called <em class="filename">carroll</em>, trying to read from
it would give an error like <tt class="literal">file not found</tt>. The
file test <tt class="literal">-l 'carroll'</tt> would report true, but
<tt class="literal">-e 'carroll'</tt> would be false: it's a symlink,
but it doesn't exist.
</p><blockquote class="footnote">
<a name="FOOTNOTE-294" /><p>[294]Deleting <em class="filename">carroll </em>would merely remove the
symlink, of course.</p> </blockquote>

<p>Since a soft link could point to a file that doesn't yet exist,
it could be used when creating a file as well. Barney has most of his
files in his home directory, <em class="filename">/home/barney</em>, but
he also needs frequent access to a directory with a long name that is
difficult to type:
<em class="filename">/usr/local/opt/system/httpd/root-dev/users/staging/barney/cgi-bin</em>.
So he sets up a symlink named
<em class="filename">/home/barney/my_stuff</em>, which points to that long
name, and now it's easy for him to get to it. If he creates a
file (from his home directory) called
<em class="filename">my_stuff/bowling</em>, that file's real name is
<em class="filename">/usr/local/opt/system/httpd/root-dev/users/staging/barney/cgi-bin/bowling</em>.
Next week, when the system administrator moves these files of
Barney's to
<em class="filename">/usr/local/opt/internal/httpd/www-dev/users/staging/barney/cgi-bin</em>,
Barney just repoints the one symlink, and now he and all of his
programs can still find his files with ease.
</p>

<p>It's normal for either <em class="filename">/usr/bin/perl</em> or
<em class="filename">/usr/local/bin/perl</em> (or both) to be symbolic
links to the true Perl binary on your system. This makes it easy to
switch to a new version of Perl. Say you're the system
administrator, and you've built the new Perl. Of course, your
older version is still running, and you don't want to disrupt
anything. When you're ready for the switch, you simply move a
symlink or two, and now every program that begins with
<tt class="literal">#!/usr/bin/perl</tt> will automatically use the new
version. In the unlikely case that there's some problem,
it's a simple thing to replace the old symlinks and have the
older Perl running the show again. (But, like any good admin, you
notified your users to test their code with the new
<em class="filename">/usr/bin/perl-7.2</em> well in advance of the switch,
and you told them that they can keep using the older one during the
next month's grace period by changing their programs'
first lines to <tt class="literal">#!/usr/bin/perl-6.1</tt>, if they need
to.)
</p>

<p>Perhaps suprisingly, both hard and soft links are very useful. Many
non-Unix operating systems have neither, and the lack is sorely felt.
On some non-Unix systems, symbolic links may be implemented as a
"shortcut" or an "alias" -- check the
<em class="emphasis">perlport</em> manpage for the latest details.
</p>

<p>To find out where a symbolic link is pointing, use the
<tt class="literal">readlink</tt> function. This will tell you where the
symlink leads, or it will return <tt class="literal">undef</tt> if its
argument wasn't a symlink:
</p>

<blockquote><pre class="code">my $where = readlink "carroll";             # Gives "dodgson"

my $perl = readlink "/usr/local/bin/perl";  # Maybe tells where perl is</pre></blockquote>

<p>You can remove either kind of link with
<tt class="literal">unlink</tt> -- and now you see where that operation
gets its name. <tt class="literal">unlink</tt> simply removes the directory
entry associated with the given filename, decrementing the link count
and thus possibly freeing the inode.<a name="INDEX-907" />
</p>



<hr width="684" align="left" />
<div class="navbar"><table width="684" border="0"><tr><td align="left" valign="top" width="228"><a href="ch13_02.htm"><img alt="Previous" border="0" src="../gifs/txtpreva.gif" /></a></td><td align="center" valign="top" width="228"><a href="index.htm"><img alt="Home" border="0" src="../gifs/txthome.gif" /></a></td><td align="right" valign="top" width="228"><a href="ch13_04.htm"><img alt="Next" border="0" src="../gifs/txtnexta.gif" /></a></td></tr><tr><td align="left" valign="top" width="228">13.2. Renaming Files</td><td align="center" valign="top" width="228"><a href="index/index.htm"><img alt="Book Index" border="0" src="../gifs/index.gif" /></a></td><td align="right" valign="top" width="228">13.4. Making and Removing Directories</td></tr></table></div>
<hr width="684" align="left" />

<img alt="Library Navigation Links" border="0" src="../gifs/navbar.gif" usemap="#library-map" />
<p><p><font size="-1"><a href="copyrght.htm">Copyright &copy; 2002</a> O'Reilly &amp; Associates. All rights reserved.</font></p>

<map name="library-map"><area shape="rect" coords="1,0,85,94" href="../index.htm"><area shape="rect" coords="86,1,178,103" href="../lwp/index.htm"><area shape="rect" coords="180,0,265,103" href="../lperl/index.htm"><area shape="rect" coords="267,0,353,105" href="../perlnut/index.htm"><area shape="rect" coords="354,1,446,115" href="../prog/index.htm"><area shape="rect" coords="448,0,526,132" href="../tk/index.htm"><area shape="rect" coords="528,1,615,119" href="../cookbook/index.htm"><area shape="rect" coords="617,0,690,135" href="../pxml/index.htm"></map>

</body></html>