上次在 V2EX 发过一个小项目 xntfs：
https://www.v2ex.com/t/1222784
当时主要是想做一个很朴素的 NTFS 读写工具：不做大而全的磁盘工具，只是把 ntfs-3g 接到 macOS 新的 FSKit 文件系统扩展上，让 NTFS 盘能像系统原生文件系统一样自动挂载、读写、推出。
这段时间继续把同一套思路往前推进了一点，现在拆成了两个项目：
App Store 下载：
这两个项目共同的目标都很简单：让 macOS 对非原生文件系统的支持少一点割裂感。
以前在 macOS 上处理这些盘，常见选择基本是 macFUSE 、商业驱动、虚拟机，或者干脆换一台 Linux / Windows 机器。能用，但体验总有一点“外挂感”：挂载路径、权限、稳定性、系统集成、自动挂载，或多或少都不像系统自己的一部分。
FSKit 出来后，这件事有了新的路径。它是 Apple 官方的用户态文件系统扩展机制。对 xntfs 和 xlinuxfs 这种场景来说，FSKit 可以完全替代 macFUSE 这一层：不需要内核扩展，也不需要 macFUSE ，DiskArbitration 可以像处理 exFAT 、MS-DOS 那样发现设备、选择模块并挂载到 /Volumes。
应用本身更像一个控制面板：看状态、看诊断、设置只读策略、打开磁盘工具或复制必要命令；真正的文件系统 I/O 由 FSKit 扩展完成。这样体验上会更接近系统原生操作：插入设备、系统识别、自动挂载、Finder 访问、正常推出。
xntfs 做的是 NTFS 。底层不是自己重写 NTFS ，而是使用成熟的 ntfs-3g ，把 libntfs-3g 接到 FSKit 的 FSVolume 操作上。
插入 NTFS U 盘后，系统可以自动挂载，读写、创建、删除、重命名这些操作都走 ntfs-3g 的逻辑。它的目标不是做一个商业级磁盘套件，而是让 macOS 获得一个更原生的 NTFS 读写入口。
这也解决了我之前一直觉得别扭的地方：NTFS 明明是非常常见的移动硬盘格式，但在 macOS 上一直像一个“外来格式”。xntfs 想做的就是把这层隔阂尽量抹平。
xlinuxfs 更有意思一些。它使用的是 lklfuse 方案，也就是把 LKL （ Linux Kernel Library ）跑在 macOS 进程内，再通过 FSKit 暴露给系统。
换句话说，ext4 、XFS 、Btrfs 这些文件系统不是重新实现一遍，而是尽量交给 Linux 自己的文件系统驱动处理。对我来说，这是这个项目最关键的点：它不是“仿 Linux 文件系统”，而是把 Linux 文件系统能力接进 macOS 的 FSKit 。
目前 xlinuxfs 支持的几个格式都可以读写。这样一来，macOS 对 NTFS 、ext4 、XFS 、Btrfs 这些常见跨系统磁盘的隔阂会小很多。Windows 盘、Linux 盘、NAS 拆下来的盘、开发测试用的镜像，都可以更自然地出现在 Finder 和 /Volumes 里。
据我目前了解，这是 lklfuse 这类方案第一次在 macOS 上通过 FSKit 做到实际可用的实现。它的意义不只是“能挂 ext4”，而是证明 macOS 也可以通过用户态 FSKit 扩展，把 Linux 文件系统驱动比较自然地接进系统挂载流程。
当然它们都不是全能磁盘工具。现在的定位还是很克制：不替代磁盘工具，不承诺修坏盘，只专注于让系统识别、挂载、读写这些文件系统。
FSKit 也有一些现实限制。比如沙盒 App 不能随便自己执行 mount、hdiutil 这类命令，某些场景下需要跳转到磁盘工具或给出可复制命令。另外文件系统扩展需要用户在系统设置里启用，低版本系统上还有一些系统设置相关的小坑。项目里做了诊断页，尽量把“插件有没有安装、有没有启用、是否有重复注册、为什么挂载失败”这些信息显示清楚。
我个人比较喜欢这个方向的一点是，它不像传统内核扩展那么重，也不像纯命令行工具那么割裂。FSKit 给了第三方文件系统一个比较“macOS 原生”的位置：系统发现设备，系统决定挂载路径，Finder 能看到，磁盘工具也能参与，用户态扩展负责真正的文件系统逻辑。
如果只看一句话：
后续代码也会开源。也欢迎有 Linux 文件系统、FSKit 、ntfs-3g 、LKL 经验的朋友一起看看，尤其是各种真实磁盘和镜像的兼容性测试。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。