52

I was running a script that iterated over all the files on my Linux system and created some metadata about them, and it threw an error when it hit a broken symbolic link.

I am newish to *nix, but I get the main idea behind linking files and how broken links come to exist. As far as I know, they are like the equivalent of litter in the street. Things that a program I'm removing wasn't smart enough to tell the package manager existed, and belonged to it, or something that got left behind in an upgrade. At first, I started to tweak the script I'm running to skip them, then I thought, 'well we could always delete them while we're down here...'

I'm running Ubuntu 14.04 (Trusty Tahr). I can't see any reason not to, but before I go ahead and run this over my development system, is there any reason this might actually be a terrible idea? Do broken symlinks serve some purpose I am not aware of?

Improve this question
1
  • 7
    Yes: see ticked answer bellow. But more importantly, this is not a solution to your problem: the script has to work properly, not just an a sanitised system. A system could become sanitised it the ½milisecond between being sanitised and the 2nd half of the script running. Also this violated the single responsibility principle and the Unix philosophy: “do one thing well”.
    – ctrl-alt-delor
    Commented Aug 23, 2014 at 15:24

6 Answers 6

Reset to default
76

There are many reasons for broken symbolic links:

  • A link was created to a target which no longer exists.
    Resolution: remove the broken symlink.
  • A link was created for a target which has been moved. Or it's a relative link that's been moved relative to its target. (Not to imply that relative symlinks are a bad idea — quite the opposite: absolute symlinks are more prone to going stale because their target moved.)
    Resolution: find the intended target and fix the link.
  • There was a mistake when creating the link.
    Resolution: find the intended target and fix the link.
  • The link is to a file which is on a removable disk, network filesystem or other storage area which is not currently mounted. Resolution: none, the link isn't broken all the time. The link will work when the storage area is mounted.
  • The link is to a file which exists only some of the time, by design. For example, the file is the cached output of a process, which is deleted when the information goes stale but only re-created upon explicit request. Or the link is to an inbox which is deleted when empty. Or the link is to a device file which is only present when the corresponding peripheral is attached. Resolution: none, the link isn't broken all the time.
  • The link is only valid in a different storage hierarchy. For example, it is valid only in a chroot jail, or it's exported by an NFS server and only valid on the server or on some of its clients.
    Resolution: none, the link isn't broken everywhere.
  • The link is broken for you, because you lack the permission to traverse a directory to reach the target, but it isn't broken for users with appropriate privilege.
    Resolution: none, the link isn't broken for everybody.
  • The link is used to store information, as in the Firefox lock example cited by vinc17. One reason to do it this way is that it's easier to populate a symlink atomically — there's no other way, whereas populating a file atomically is more complex: you need to create the file content under a temporary name, then move it into place, and handle stale temporary files left behind by a crash. Another reason is that symlinks are typically stored directly inside their inode on some filesystems, which makes reading them faster than reading the content of a file.
    Resolution: none. In this case, removing the link would be detrimental.

If you can determine that a symlink falls into the first category, then sure, go ahead and delete it. Otherwise, abstain.

A program that traverses directories recursively and cares about file contents should usually ignore broken symbolic links.

Improve this answer
7
  • symlinks are (typically) not contained within their parent directory. However on some filesystems the link target is stored in the inode.
    – James Youngman
    Commented Aug 24, 2014 at 13:46
  • Very good list. I have a bunch of links that fall into both type 4 and 6. They point into a filesystem I mount with SSHFS. When the filesystem is not mounted, they're type 4; when the filesystem is mounted, only I can access it, so they're type 6 for everyone else (even root).
    – Barmar
    Commented Aug 27, 2014 at 20:53
  • One more possible reason for a broken symlink: a symlink to an actual file that only exists some of the time. E.g. in a work flow with deep paths, you might have a symlink to a work file (for convenience) which is deleted when the work flow is complete, but will be recreated during the next use of that work flow. /dev/modem is kind of like that because the actual device file it points to only exists when the physical device is connected.
    – Joe
    Commented Aug 30, 2014 at 4:57
  • quite a comprehensive answer !
    – njzk2
    Commented Nov 12, 2014 at 19:22
  • 1
    @MichaelDurrant Uh? The point is that the downside (or lack thereof) depends on how the broken symlink came to be.
    – Gilles 'SO- stop being evil'
    Commented Nov 12, 2014 at 21:20
22

Do not blindly remove all dangling symbolic links. They may exist just to carry some information, and may be safer than normal files since a symlink creation is atomic.

For instance, Firefox creates a lockfile "lock" that is a symlink whose value has a form like "IP_address:+PID".

Improve this answer
2
  • 1
    So like, a program may populate an empty file dynamically that one of these symlinks is a broken link to, while the program isn't running? Or it may just be a piece of information?
    – blanket_cat
    Commented Aug 23, 2014 at 13:36
  • 1
    @knotech The purpose of some symlinks (not necessarily associated with a running program) may be just to exist. Their value either is meaningless or conveys some particular information; in both cases, in general, they point to nothing. There's no empty file, just a symlink. Note also, as an example, the case of gcc builds, which create "stamp-bits" symlinks pointing to themselves: gcc.gnu.org/ml/libstdc++/2011-02/msg00014.html
    – vinc17
    Commented Aug 23, 2014 at 15:04
6

Both the fnord and the Gatling webserver use the Unix filesystem as their configuration database (as opposed to, say, Microsoft IIS, which uses the Windows registry, or Apache, which uses a complex-to-parse configuration file).

For example, virtual hosts are just directories, and creating a new virtual host is as simple as

mkdir www.example.com:80

Configuring which files to serve?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

Configuring which files to execute as CGI and which to serve?

chmod a-x plain_file.html
chmod a+x cgi_script.html

And lastly (and relevant to this question): configuring a redirect?

ln -s 'http://www.google.com/?q=awesome+query+site:www.example.com' search.html

You'll now have a symlink called search.html which points nowhere, but it is crucial to the working of your site.

Improve this answer
0

A symlink might point to a yet emty location just to force the creation at a specific filesystem location or name.

So no - do not blindly remove them.

Improve this answer
0

A significant downside to deleting stale symbolic links is that you lose the reference to where they used to point to which can be quite valuable!

Say I have a symbolic link for a file called "send_to" which points to /Users/myname/tmp and suppose that /Users/myname/tmp doesn't exist.

With the symbolic link I know where the file was intended to be. For example, in this case I can see that it's a temporary directory and if I need to "fix" it, I should consider a temporary directory as the destination.

Similarly a link "my_config" that point to /etc/conf_file that goes 'bad' because the conf_file has been renamed to confirmation_file is still useful information. If you went to the /etc directory and did an ls and saw the file called conf_file was missing but confirmation_file was there you might have enough info to now fix the link.

Improve this answer
-2

Quoting from The Linux Command Line (best book ever for Linux newbies, and you can download it for free here):

Picture this scenario: A program requires the use of a shared resource of some kind contained in a file named “foo,” but “foo” has frequent version changes. It would be good to include the version number in the filename so the administrator or other interested party could see what version of “foo” is installed. This presents a problem. If we change the name of the shared resource, we have to track down every program that might use it and change it to look for a new resource name every time a new version of the resource is installed. That doesn't sound like fun at all.

Here is where symbolic links save the day. Let's say we install version 2.6 of “foo,” which has the filename “foo-2.6” and then create a symbolic link simply called “foo” that points to “foo-2.6.” This means that when a program opens the file “foo”, it is actually opening the file “foo-2.6”. Now everybody is happy. The programs that rely on “foo” can find it and we can still see what actual version is installed. When it is time to upgrade to “foo-2.7,” we just add the file to our system, delete the symbolic link “foo” and create a new one that points to the new version. Not only does this solve the problem of the version upgrade, but it also allows us to keep both versions on our machine. Imagine that “foo-2.7” has a bug (damn those developers!) and we need to revert to the old version. Again, we just delete the symbolic link pointing to the new version and create a new symbolic link pointing to the old version.

So no, I would not delete symbolic links as that will certainly be a headache moving on, and you run the risk of seriously messing up your system.

Improve this answer
1
  • 6
    The OP wasn't advocating removing symlinks tout court - only broken symlinks, i.e. symlinks that do not point to any current existing file.
    – LSerni
    Commented Aug 23, 2014 at 17:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .