Mac OS X 的文件系统

[ 整理自《 Mac OS X Help Desk 》中文译版 ]

万维网（ World Wide Web ）是在运行基于 UNIX 的操作系统的一台 NeXT 计算机上发明出来的，所以 Web 地址看起来非常类似于文件的 UNIX 路径名也就不令人奇怪了。用一条路径来描述一个 Web 页面在 Internet 上的位置所使用的约定，基本上就是 Mac OS X 描述一个文件或文件夹在文件系统中的位置所使用的同一种机制。

首先需要明确的一点：不管用户将磁盘分成了几个区，也不管用户拥有多少个存储设备（比如多个内置硬盘，以及接入的外置硬盘），文件系统的根始终是当前系统所在的宗卷（也叫启动宗卷），用一个正斜杠（/）来访问根。而其他宗卷都挂载在 /Volumes 文件夹下，这个 Volumes 默认是隐藏文件夹，一般用户看不到，在“磁盘工具”或“系统概述”关于宗卷的部分，都可以查看每个宗卷的挂载点。虽然在操作系统的文件系统中，宗卷都以文件夹的方式去访问（比如，一个宗卷名叫“ FireWire HD ”外置火线硬盘的访问地址是 /Volumes/FireWire HD ），但为了不使用户感到困惑，在图形用户界面的 Finder 窗口或桌面上，会用硬盘或其光盘或者他类似图标显示给用户访问。

（题外话：在 UNIX 类操作系统中，所有设备都以文件或文件夹方式访问，比如，要在打印机上打印，那就是给一个叫打印机的文件写入数据，而要在扫描仪上扫描图像，则是通过从一个叫扫描仪的文件上读取数据来实现，至于硬件具体怎么处理这些操作系统读写过来的数据，则由驱动程序来负责解析。这种统一数据接口的好处可以去问问驱动开发者。而且由于接口统一，操作系统不需要为不同的硬件设计不同的功能，减少复杂程度也保证了稳定。在 UNIX/Linux 中，驱动程序不兼容的时候，最多是降低了硬件的性能；而如果是在 Windows 中，一个不兼容的硬件或硬件驱动程序则会让系统摆一个蓝脸给你看。）

一个以正斜杠（/）开头的路径是一个绝对路径，表示从文件系统的根开始来指向一个文件或文件夹；而相对路径则表示该路径是从用户当前所处的位置开始指向一个文件或文件夹。

另外还有一些快捷指向方式：
用户的主目录可以用否定符（~）来引用，比如，用 ~sp4navy/Documents 来指向用户名为 sp4navy 的帐户的“文稿”文件夹，而 ~/Documents 则表示当前当前登录帐户的“文稿”文件夹。
以一个点开头的路径表示从当前的工作文件夹开始指向；以两个点开头的路径表示从当前的工作文件夹的父文件夹（上一级文件夹）开始指向。这个对于网页设计者而言也是非常熟悉的了。

对于一些系统级的文件夹，系统认为普通用户不需要使用，为了安全和美观，便将它们隐藏。还有，根据一个很早就开始使用的约定，所有以点开头的文件和文件夹也不会出现在 Finder 中。如果要访问这些文件夹，可以使用“转到文件夹...”手动填路径来实现。

Mac OS X 对文件管理是非常有序的，比如仅供当前用户使用的资源文件放在 ~/Library 下，而根目录下的 /Library 则对所有用户有效，至于 /System/Library 中的资源文件由系统专属，不允许也不推荐用户去动它们。
那么，诸如字体、框架、参数预置之类的数据在不同的地方都有，系统需要搜索多个位置来寻找资源，这个搜索有个先后顺序， Mac OS X 查找资源的先后顺序如下：
1、Users （ ~/Library ）
2、Local （ /Library ）
3、Network （ /Network/Library ）
4、System （ /System/Library ）

如果相同的文件在不同位置都有，那么系统会根据当前用户的属性来判断使用哪一个，对于普通用户，自然是按 1 > 2 > 3 > 4 的方式来选择。

Mac OS X 支持好几种宗卷格式，不过最常用的是 Mac OS 扩展（ HFS+ ）格式，从 Mac OS 8.1 以来一直是推荐格式。这个格式不是大小写敏感的，但大小写保护，意思是：你无法在同一个位置同时保存 File1 和 file1 两个文件，因为 Mac OS X 认为它们是相同的，但是，如果你一开始保存的是 File1 ，那么它始终是 File1 而不会变成 file1 。从 Mac OS X Server 10.2.2 开始，这个格式引入了“日志式”概念，它会记录文件每次的更改，以保护文件不受断电或者宕机的影响。从 Mac OS X 10.3 开始，这个概念全面应用。
另外， HFS+ 支持资源分支，很有用的东东，后面会详细介绍。

然后是 Mac OS 标准（ HFS ）格式，比较旧，存储空间利用率很低， Mac OS X 不能安装在这上面。基本上这个格式没有使用的意义，但是，如果你正在使用很古老的系统（ Mac OS 8.1 以前），你可能需要它，因为它们不识别 HFS+ 。

再然后是 UNIX 文件系统（ UFS ），这种格式兼容其他 UNIX 类操作系统，它有一个重要特性：它是大小写敏感的，所以你可以在同一个位置同时保存 File1 和 file1 。如果你需要开发 UNIX 应用软件，这个是比较理想的格式。需要注意的是： UFS 对 Classic 环境和 Mac OS 9 是不可见的。

MS-DOS 格式（ FAT ），这个不用多说，和 Windows 兼容。需要注意的是：在“磁盘工具”中用户无法直接指定使用 FAT 16 还是 FAT 32 格式，“磁盘工具”会根据宗卷的大小来自动选择（虽然 FAT 32 的空间利用率更好，但它的文件表需要占用的空间也大，所以对于一些小宗卷 ---- 比如软盘 ---- 可能 FAT 16 更合适）。如果一定要自己指定，则可能需要用 Shell 来格式化。

一般情况下，我们只用 HFS+ 格式。在这个文件系统上，每个文件都有两个分支（ Fork ）：数据分支（ Data fork ）和资源分支（ Resource fork ）。其中的数据分支和我们普通的文件的概念相同，而资源分支则用来存储其它 Mac OS X 特性的信息，比如自定义图标、用户指定的打开方式（单独指定的“打开方式”保存在该文件的资源分支中，而“应用到所有”的“打开方式”则保存在 ~/Library/Preferences/com.apple.LaunchServices.plist 文件中）等。在 Finder 窗口中，不管是否显示隐藏文件，我们都只能看到一个文件（数据分支），对资源分支需要通过其他间接操作（如果在“显示简介”里贴自定义图标，或者指定打开方式等），但一些程序员工具也可以单独对资源分支进行处理。
由于只有 Mac OS X 才能识别资源分支，所以在不同的文件系统中交换文件的时候，其他的系统会把资源分支舍弃掉。为了避免丢失这些信息，在需要途径非 Mac OS X 的系统之前，应该先转换，比如 BinHex ，或者制作成磁盘映像。需要注意：标准的 zip 和 tar 格式都不支持资源分支，但系统自带的“归档”功能以及 StuffIt 等压缩软件可以把资源分支独立成一个文件，然后在 Mac OS X 上解压缩时能识别并还原回去，以此来保存资源分支。当在 Mac OS X 上直接把一个文件保存在 FAT 等不支持资源分支的宗卷上时，它也会把资源分支独立成一个文件（和原文件同名，但添加了“ ._ ”前缀），以便在 Mac OS X 上访问该文件时资源分支得以重现，在 Windows 上打开由 Mac OS X “归档”出来的 zip 文件也是如此。其实，这个是 Mac OS X 所使用的影子文件（ AppleDouble ）的方式。而如果你在 Windows 使用该文件时将 ._ 文件删除，那么原来资源分支上的数据也就没了~~
突然想到 Backup 3.1 ，顺便说一下，在备份前， Backup 会先扫描所有符合备份要求的文件，然后有一个标记的过程，这个过程会把需要备份的资源分支提取出来单独保存，也就是说， Backup 是把文件的数据分支和资源分支分开保存的，所以你直接爆开备份文件直接挂载里面的映像时，所有的文件都没有资源部分，而需要用 Backup 还原文件才能再把数据分支和资源分支合并起来。同时，如果备份文件中资源分支数据量过多（比如大量的文件都有自定义图标），那么这个“标记过程”将会比较慢，而且 ~/Library/Application Support/Backup/Backup Library 里的备份库也会很大。

（题外话：相信了解了资源分支之后，部分新用户对于自定义图标的疑惑应该有所了解了。）

Mac OS X 中还有一种叫“包”的机制（《 Mac OS X Help Desk 》的中文译版错误百出，比如 Disk Image 本来叫“磁盘映像”，它说是“磁盘图像”；“钥匙串” Keychain 它说是“键链”，貌似是金山词霸直译，令人哭笑不得。而在这里，它翻译成“束”，我也不敢“尽信书”，鉴于 Mac OS X 中显示的是“显示包内容”而不是“显示束内容”，所以我打算还是说“包”机制好了）。比如 .app 应用程序、 .bundle 捆绑资源、 .component 组件、 .plugin 插件、 .pkg 安装包等，它以单个文件的形式将一些结构化组织好的文件们显示给用户。这大大方便用户管理和使用一些具有集体组织性的文件。

Windows 上充分迷信扩展名，一个什么样的扩展名就代表一个什么类型的文件；而 Linux 则有点过分放纵扩展名，基本上扩展名仅仅是一个指示，在 Linux 上就算是一个 .txt 也是可以执行的。相比之下， Mac OS X 则比较中立，即不严格约束扩展名，也不对普通用户放纵。在连按（在 Windows 上一般说“双击”，不过在 Apple 的文档中用“连按”）一个文件的时候， Mac OS X 先在资源分支上查找这个文件的创建者（这个创建者是指生成这个文件的应用程序，而不是保存这个文件的用户）信息，如果它没有被单独指定过打开方式，那么会直接用该应用程序打开；如果没有相关信息，再根据扩展名来判断。
细心的用户会发现 Microsoft Office 2004 自己安装的部分字体没有扩展名，不过由于资源分支里已经标示了它们是字体文件，所以是可以正常用的，因为 Mac OS X 优先判断的是资源分支里的信息。但如果去掉资源分支，那么它们就变成了没有扩展名不知道任何信息未知文件，就不知道干什么用了。
一般情况下，普通用户不需要去直接干涉资源部分的内容，系统也不提供这样的功能。但是，如果真的需要，那么可以用 Shell 或者第三方工具来藐视扩展名直接指定文件类型等等。

注意， Shell 中 cp 和 mv 命令是忽略资源分支的，复制或移动过的文件的资源分支将丢失。安装了 Developer Tools 的用户可以用 CpMac 和 MvMac 等 Mac OS X 特有的命令，它们用法和 cp 和 mv 一样，但支持资源分支。
另外还有 ditto 命令，如果要复制一个文件并保留它的资源分支，那么可以： ditto -rsrcFork 源文件 目标文件
还有， Renamer4Mac 用户可以发现在预置里可以选择是通过“系统更名”还是通过“ Finder 更名”。其中，“ Finer 更名”就像普通在 Finer 里更名操作一样，只是自动完成而已。而“系统更名”其实是借助 Shell ，操作速度快，但由于忽略了资源分支，所以更名之后的文件的资源分支将丢失。