解除链接的速度比rm快吗？

评论

“过早的优化是编程中所有邪恶（或至少是大多数邪恶）的根源。” -Donald Knuth en.wikiquote.org/wiki/Donald_Knuth

#1 楼

两者都是对同一基本功能（即unlink()系统调用）的包装。

权衡用户空间实用程序之间的差异。

rm(1)：


更多选项。
更多反馈。
健全性检查。
由于上述原因，单个调用的速度较慢。
可以使用多个参数调用同时。

unlink(1)：


缺乏健全性检查。
无法删除目录。
无法递归。
/>一次只能接受一个参数。
由于它的简单性，单次调用的边际精简。
与给rm(1)提供多个参数相比，速度较慢。

与以下内容的区别：

$ touch $(seq 1 100)
$ unlink $(seq 1 100)
unlink: extra operand `2'

$ touch $(seq 1 100)
$ time rm $(seq 1 100)

real    0m0.048s
user    0m0.004s
sys     0m0.008s

$ touch $(seq 1 100)
$ time for i in $(seq 1 100); do rm $i; done

real    0m0.207s
user    0m0.044s
sys     0m0.112s

$ touch $(seq 1 100)
$ time for i in $(seq 1 100); do unlink $i; done

real    0m0.167s
user    0m0.048s
sys     0m0.120s


但是，如果我们谈论的是对系统unlink(2)函数的纯净调用，我现在意识到这可能不是您要解释的。

您可以在目录和文件上执行系统unlink()。但是，如果目录是其他目录和文件的父目录，则到该父目录的链接将被删除，但子目录将悬空。很不理想。

编辑：

对不起，澄清了unlink(1)和unlink(2)之间的区别。平台之间的语义仍然会有所不同。

评论

从技术上讲，即使不是全部，在大多数文件系统上也可以保留孤立的目录/文件。修复此问题通常意味着运行文件系统修复工具。在Unix / Linux上，这些工具称为“ fsck”，并且针对不同的文件系统有一些特定的变体。如果他们确实恢复了某些东西，通常会将其保留在名为“ lost + found”的目录中

– ConcernedOfTunbridgeWells
09年7月10日在10:01
正确。 rm将从树的底部向上递归。您可以使用以下方法演示如何操作：mkdir -p 1/2/3;触摸1/1/1/2/2 1/2/3/3; rm -ri 1.如果取消链接父目录，则子级占用的空间应该丢失，直到fsck发现差异为止。

–丹·卡利
09年7月10日在10:03
你在说什么？ $ mkdir -p 1/2/3 $取消链接1取消链接：无法取消链接“ 1”：目录引起“内存”泄漏的用户需要fsck吗？不太可能！

–托马斯
09年7月10日在11:36
Linux和FreeBSD联机帮助页都明确指出，尝试在目录上运行unlink（）时它将失败。

–托马斯
09年7月10日在11:44
事实证明，带有UFS的Solaris确实允许root取消链接非空目录。虽然不是普通用户。还有别的吗？在Solaris上不是ZFS，在Linux或FreeBSD上不是任何东西。

–托马斯
09年7月10日在13:17

#2 楼

在POSIX规范级别，对rm所做的规定比取消链接的规定要严格得多。

如果您的脚本必须跨操作系统运行，则使用rm可能会更好地实现结果的可移植性。 br />

#3 楼

删除最慢的部分是文件系统代码和磁盘内容，而不是unlink（）系统调用的用户空间准备。

即：如果速度差异很重要，那么您不应该存储数据在文件系统上。

unlink只是rm“ light”。 rm具有更多功能，但功能相同。