删除系统中所有损坏的符号链接是否有缺点？

Question

我正在运行一个脚本，它遍历我的 Linux 系统上的所有文件并创建了一些关于它们的元数据，当它遇到一个损坏的符号链接时它会抛出一个错误。

我是 *nix 的新手，但我了解链接文件背后的主要思想以及断开的链接是如何存在的。据我所知，它们就像街上的垃圾一样。我正在删除的程序不够聪明，无法告诉包管理器存在并属于它，或者在升级中留下的东西。起初，我开始调整我正在运行的脚本以跳过它们，然后我想，'好吧，当我们在这里时，我们可以随时删除它们......'

我正在运行Ubuntu 14.04 (Trusty Tahr)。我看不出有什么理由不这样做，但是在我继续在我的开发系统上运行它之前，是否有任何理由这实际上可能是一个糟糕的主意？损坏的符号链接是否有我不知道的用途？

Answer 1

符号链接断开的原因有很多：

• 已创建指向不再存在的目标的链接。
  解决方案：删除损坏的符号链接。
• 为已移动的目标创建了链接。或者它是相对于其目标移动的相对链接。（并不是暗示相对符号链接是一个坏主意——恰恰相反：绝对符号链接更容易因为它们的目标移动而变得陈旧。）
  解决方案：找到预期的目标并修复链接。
• 创建链接时出错。
  解决方案：找到预期目标并修复链接。
• 该链接指向可移动磁盘、网络文件系统或其他当前未安装的存储区域上的文件。解决方案：无，链接不会一直断开。挂载存储区后，链接将起作用。
• 根据设计，该链接指向一个仅在某些时候存在的文件。例如，文件是进程的缓存输出，当信息陈旧时会被删除，但只有在明确请求时才会重新创建。或者链接指向收件箱，该收件箱在为空时被删除。或者该链接指向一个设备文件，该文件仅在连接了相应的外围设备时才存在。解决方案：无，链接不会一直断开。
• 该链接仅在不同的存储层次结构中有效。例如，它仅在 chroot jail 中有效，或者由 NFS 服务器导出并且仅在该服务器或其某些客户端上有效。
  解决方案：无，链接并未在任何地方断开。
• 链接对您来说已断开，因为您缺乏遍历目录以到达目标的权限，但对于具有适当权限的用户而言，链接并未断开。
  解决方案：无，并非所有人都断开了链接。
• 该链接用于存储信息，如vinc17 引用的Firefox 锁定示例。这样做的一个原因是原子地填充符号链接更容易——没有其他方法，而原子地填充文件更复杂：您需要以临时名称创建文件内容，然后将其移动到位，并且处理崩溃留下的陈旧临时文件。另一个原因是符号链接通常直接存储在某些文件系统的 inode 中，这使得读取它们比读取文件内容更快。
  分辨率：无。在这种情况下，删除链接将是有害的。

如果您可以确定符号链接属于第一类，那么当然可以继续删除它。否则，弃权。

递归遍历目录并关心文件内容的程序通常应该忽略损坏的符号链接。

Answer 2

不要盲目删除所有悬空的符号链接。它们可能只是为了携带一些信息而存在，并且可能比普通文件更安全，因为符号链接的创建是原子的。

例如，Firefox 创建一个锁文件“lock”，它是一个符号链接，其值的形式类似于“IP_address:+PID”。

Answer 3

无论是fnord和加特林Web服务器使用Unix文件系统作为其配置数据库（而不是，比方说，微软的IIS，它使用Windows注册表，或Apache，它采用了复杂的对解析配置文件）。

例如，虚拟主机只是目录，创建一个新的虚拟主机就像

mkdir www.example.com:80

配置要提供哪些文件？

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

配置哪些文件作为 CGI 执行，哪些文件提供服务？

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

最后（与这个问题相关）：配置重定向？

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

您现在将拥有一个称为search.html无处指向的符号链接，但它对您网站的工作至关重要。