是否存在一些常见的符号链接陷阱?

是否存在一些常见的符号链接陷阱?

我将服务器迁移到 Amazon EC2 的迁移策略的一部分涉及使用符号链接将安装和文件保存在服务器上的“标准”位置,但将日志文件、数据等的实际存储在 EBS 存储中,以实现持久性。服务器启动后,我运行脚本,创建指向存储在 EBS 上的配置文件和数据的符号链接,以将服务器“转换”为我需要的设置。

由于我不是真正的 Linux 系统管理员(小型公司开发人员),所以我担心使用符号链接时可能出现任何我可能不知道的陷阱。我担心的是破坏软件包或其他应用程序可能不喜欢使用符号链接的问题。

使用符号链接是否存在一些常见问题?或者它们是否非常万无一失?

答案1

如果您仅软符号链接目录(而不是文件),那么它们在大多数情况下应该表现得完全透明。

您可能遇到的唯一问题是,某些应用程序解析后会继续引用链接的真实路径。如果您稍后选择更改链接源,则可能会导致问题。

答案2

是的,远离“硬”链接,因为您很容易用它们造成混乱。硬符号链接只是同一文件在文件系统不同部分的“重新出现”,即它实际上在文件系统的目录结构中创建了第二个条目,并直接链接到文件数据。它们有其用途,但一般来说,您最好使用“软”符号链接,它们类似于 Windows 快捷方式(尽管在实现上有很大不同),因为它们只是指向原始文件的指针。这些是您最好的选择。

删除软符号链接会删除该链接。如果不小心,删除硬符号链接可能会删除该文件。

答案3

有人指出,硬链接会在文件系统中生成第二个条目。您只能在同一分区上将其用于文件,而不能用于目录。如果您删除指向某个文件的所有硬链接,则该文件会被删除。

软链接,即符号链接,只需在目录中创建一个条目,即可让您轻松地看到真实文件的存储位置。

你无法在另一端知道多个符号链接指向一个文件。如果你移动或删除该文件,所有符号链接都会中断。

适度使用符号链接是没问题的。如果你发现一个符号链接指向另一个符号链接,而这个符号链接在到达真实文件之前又指向另一个符号链接,那么你应该仔细想想。那么你可能做错了什么……

相关内容