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

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

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

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

我在跑乌班图14.04(值得信赖的塔尔)。我看不出有什么理由不这样做,但在我继续在我的开发系统上运行这个之前,有什么理由这实际上可能是一个糟糕的主意吗?损坏的符号链接是否有某种我不知道的用途?

答案1

符号链接损坏的原因有很多:

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

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

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

答案2

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

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

答案3

这俩福诺德加特林Web 服务器使用 Unix 文件系统作为其配置数据库(与使用 Windows 注册表的 Microsoft IIS 或使用难以解析的配置文件的 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.htmlwhich 的符号链接,该链接无处可去,但它对于您网站的运行至关重要。

答案4

删除过时的符号链接的一个显着缺点是您会丢失对它们曾经指向的位置的引用,而这可能是非常有价值的!

假设我有一个名为“ send_to”的文件的符号链接,它指向/Users/myname/tmp并假设该文件/Users/myname/tmp不存在。

通过符号链接我知道文件在哪里故意的成为。例如,在这种情况下,我可以看到它是一个临时目录,如果我需要“修复”它,我应该考虑将临时目录作为目标。

my_config类似地,指向该链接的链接“ ”/etc/conf_file会变得“错误”,因为conf_file已重命名为confirmation_file 仍然是有用的信息。如果您转到该/etc目录并执行了操作ls,发现所调用的文件conf_file丢失了,但confirmation_file您可能有足够的信息来修复链接。

相关内容