Linus Torvalds和OS X文件系统

早在2008年，Linus Torvalds在一次采访中就曾著名地表示：“在某些方面，OS X实际上要比Windows差。它们的文件系统完整且毫无用处，这很可怕。” 我一直在寻找有关他为什么对OS X文件系统（大概是HFS +）有这种看法的更多详细信息，但是我什么都找不到。

Linus肯定不会不喜欢基本的Unix文件系统模型，而且我怀疑他讨厌HFS +不区分大小写。尽管对他的评论表达了多么挑衅，但我怀疑这完全没有道理。由于该评论是针对OS X进行编程的，因此我怀疑他的观点可能基于性能，健壮性，操作系统接口或类似的东西。有谁知道2008年时代的Linus对2008年时代的HFS +有何抱怨？

莱纳斯发表评论的“问答环节”的笔录已经发布，但似乎并没有要求他详细说明。我不确定是否在其他地方写下了对他对HFS +的观点的更深入的分析。

对于其他人对此事的分析，您可以看一下John Siracusa的Mac OS X评论。特别是Mac OS X Lion的一个，其标题为“ HFS +怎么了”。我认为最突出的一点是（强调我的意思）：

并发，以正确的字节顺序写入的元数据，亚秒级的日期精度，对海量卷的支持以及对稀疏文件的支持都是Unix文件系统的常见功能。Mac OS X当然是建立在Unix基础上的。当HFS +从经典Mac OS移植到Mac OS X时，需要对其进行扩展以支持Unix文件系统所期望的一些最低限度的功能集。

其中一些功能很容易安装，但是很难在不破坏向后兼容性的情况下将其他功能添加到文件系统中。一个特别令人恐惧的例子是在HFS +上实现硬链接。为了跟踪硬链接，HFS +在卷的根级别的隐藏目录内为每个硬链接创建一个单独的文件。隐藏的目录一开始就是令人毛骨悚然的，但真正的恐惧来自于您记得Time Machine是使用硬链接实现的，以避免不必要的数据重复。

这里的重点是Mac OS X使用的文件系统甚至不是为Unix系统设计的，它是为经典Mac OS设计的，并进行了修补以实现Mac OS X 10.0的功能，同时保持向后兼容性。苹果随后使用相同的修补方法而不是“从头开始设计”方法，实现了Mac OS X 10.7中现在具有的其他功能（新闻发布，元数据，文件系统事件...）。我不确定如何从非技术角度进行解释，但是您可以说所有这些附加功能都基于经典的Mac OS基础，而该基础从未被设计为支持它们。这意味着解决方案并不尽如人意。Siracusa继续讨论的示例是，Apple在HFS +的限制内工作时必须用于硬链接的解决方案对硬件故障过于敏感，而且事实是，HFS +也从未设计过考虑数据本身诚信。当然，在Mac OS X 10.0中，保持与经典Mac OS的兼容性是一个理想的限制，但在Mac OS X 10.7中，实际上不再存在。

尽管我不是操作系统专家，并且从Windows来之后我才刚开始使用OSX，但我认为自己是Windows的PowerUser，并且在Linux中相当称职。从这种背景出发，令我感到惊讶的是，在像OSX这样相当现代的OS中，文件系统存在一些奇怪现象，例如文件名称的“混合”方式。

我了解Linus关于HFS +的问题源于同一点：根据我对问题的研究发现，HFS +使用Unicode存储文件的名称，但是当文件使用“扩展”或NON-ASCII字符（如á， é，í，ó，ú，ñ（来自西班牙语或德语中的ü），Unicode提供了两种对名称进行编码的方式，OSX在存储时无提示地对编码进行“规范化”……文件创建和OSX消耗，但与其他操作系统，该事实的用户，当你共享信息名的文件的变化，使得对所有类型的奇怪的行为...

恰当的例子：过去8年来，我一直在Subversion中跟踪我的工作“工件”（文件，文档等）。移至Mac时，我获得了Mac的SVN客户端，并在对相关目录进行签出后，发现所有带有重音符号的文件似乎都丢失了，而同名的新文件则显示为非版本。深入研究它的问题是文件系统中的文件是苹果编码的，而存储库中的数据使用了另一种（完全有效和合法的）Unicode编码...

我认为，这是对我的数据的粗暴“篡改”。Apple DOES理解文件名编码的两种格式（在Windows中访问共享或从Windows使用USB记忆棒显示正确的文件名，等等），但是在文件创建时，它决定“它知道更好”并只是重命名了文件。 ..

再次，大多数用户不会注意到-在他们复制文件或重命名文件，然后将其放回原始文件之前，最后得到两个看起来相同的文件！！！）

John Siracusa和Dan Benjamin讨论了HFS +在Hypercritical＃56中的一些缺点。

他们解决了HFS +中的数据损坏问题，并考虑了ZFS的某些功能。