 |  |
| |
Symbolic links ( Section 10.5) have one problem. Like good bread, they become "stale" fairly easily. What does that mean?
Consider the following commands:
% ln -s foo bar % rm foo
What happens if you run these two commands? Remember that the link bar is a pointer: it doesn't have any real data of its own. Its data is the name of the file foo. After deleting foo, the link bar still exists, but it points to a nonexistent file. Commands that refer to bar will get a confusing error message:
% cat bar cat: bar: No such file or directory
This will drive you crazy if you're not careful. The ls command will show you that bar still exists. You won't understand what's going on until you realize that bar is only a pointer to a file that no longer exists.
The commands ls -Ll or ls -LF will show an unconnected symbolic link. The -L option means "list the file that this link points to instead of the link itself." If the link points nowhere, ls -L will still list the link.
There are many innocuous ways of creating invalid symbolic links. For example, you could simply mv the data file foo. Or you could move foo, bar, or both to some other part of the filesystem where the pointer wouldn't be valid anymore.
One way to avoid problems with invalid links is to use relative pathnames (Section 1.16) when appropriate. For instance, using relative pathnames will let you move entire directory trees around without invalidating links (provided that both the file and the link are in the same tree). Here's an example: assume that you have the file /home/mars/john/project/datastash/input123.txt. Assume that you want to link this file to /home/mars/john/test/input.txt. You create a link by giving the command:
% cd /home/mars/john/test % ln -s ../project/datastash/input123.txt input.txt
At some later date, you hand the project over to mary, who copies Section 10.13) the entire project and test data trees into her home directory. The link between input.txt and the real file, input123.txt, will still be valid. Although both files' names have changed, the relationship between the two (i.e., the relative path from one directory to the other) is still the same. Alternatively, assume that you are assigned to a different computer named jupiter and that you copy your entire home directory when you move. Again, the link remains valid: the relative path from your test directory to your datastash directory hasn't changed, even though the absolute paths of both directories are different.
On the other hand, there is certainly room for absolute pathnames (Section 31.2). They're useful if you're more likely to move the link than the original file. Assume that you are creating a link from your working directory to a file in a master directory (let's say /corp/masterdata/input345.txt). It is much more likely that you will rearrange your working directory than that someone will move the master set of files. In this case, you would link as follows:
% ln -s /corp/masterdata/input345.txt input.txt
Now you can move the link input.txt anywhere in the filesystem: it will still be valid, provided that input345.txt never moves.
Note that hard links never have this problem. With a hard link, there is no difference at all between the link and the original -- in fact, it's unfair to call one file the link and the other the original, since both are just links to the same inode. You can't even tell which one came first.
-- ML
|  | |
| 10.5. Creating and Removing Links |  | 10.7. Linking Directories |
Copyright © 2003 O'Reilly & Associates. All rights reserved.