18.6 Stale Symbolic Links

Symbolic links 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 when you do this? 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. An ls 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 command 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. -JP  ]

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 ( 1.21 ) when it is appropriate. For example, using relative pathnames will let you move entire directory trees around without invalidating links (providing 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 ( 18.16 ) 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 ( 14.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.

In article 16.28 , we give a script for detecting stale symbolic links.

Note that hard links ( 18.4 ) 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.