强行创建目录硬链接?

Har*_*ikk 5 shell hard-link ln

我理解为什么几乎每个 unix 版本都不允许目录的硬链接(实际上 OS X 上的 HFS+ 是我唯一知道的,但即使这样也不容易做到)。但是,理论上所有文件系统都支持硬链接目录,因为所有目录都包含至少一个指向自身的额外硬链接,以及指向其父目录的子目录中的额外硬链接。

现在,我意识到如果误用硬链接可能会很危险,因为它会创建很少有程序会检查的循环结构,从而陷入无限循环。但是,我希望使用硬链接来创建适用于任何 Unix 的 Time Machine 风格的备份。我不相信这种结构是危险的,因为链接只是指向以前的备份;不应存在​​周期性联系的风险。就我而言,我目前只是使用 rsync 创建到现有文件的硬链接,但这又慢又浪费,特别是在备份非常大的情况下,尤其是如果我已经知道哪些目录没有改变。

考虑到这一点,有没有办法强制在 unix 变体上创建目录硬链接?ln大概是不好的,因为这是许多 unix 风格为了防止硬链接目录而对其进行限制的地方,并且ln支持硬链接目录的版本特别声明操作可能会失败。但是对于知道风险并且知道他们的用例是安全的人来说,有没有办法实际创建链接呢?非常适合 shell 脚本,但如果我需要编译一个小程序来完成它,那么我想我可以。

Chr*_*own 5

不要这样做。如果您希望备份系统使用硬链接来节省空间,最好使用 rsync 与--link-dest,这将适当地硬链接文件以节省空间,而不会导致由此引起的问题(即,目录之间的硬链接会损坏文件系统,并会导致它报告错误的 inode 计数 + fsck 失败 + 由于不是 DAG,通常具有未知的语义)。

  • 这将导致它“fsck”失败。`Pass 2:检查目录结构` `/ (2) 中的条目'bar' 是到目录/foo (12) 的链接。` `Clear<y>? ` 还在 inode 中留下错误的引用计数(后来的 fsck 消息) (2认同)
  • 好吧,我没想到错误的 inode 计数。但关键是,OP 实际上想“使用”这个,而不仅仅是出于求知欲。这显然不是一个明智的备份策略。甚至半神智。所以这个评论是为了确保 OP 意识到这一点。 (2认同)