Is there a downside to deleting all of the broken symbolic links in a system?
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?
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”.
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.
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.
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.
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.
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.