macOS M1 上虚拟文件系统 (VFS) 内核扩展的替代

如何解决macOS M1 上虚拟文件系统 (VFS) 内核扩展的替代

我们为 macOS 上的虚拟文件系统 (VFS) 开发了内核扩展 (KEXT)，以便将我们的软件与外部程序（如 Adob​​e InDesign 或 Microsoft Word）集成。我们的许多客户都在使用我们的软件和 KEXT。

看起来 KEXT 已被弃用，并且可能会在未来版本的 macOS 中完全删除，尤其是在基于 Apple Silicon 的计算机上。见例如Apple 在其 security guide 中的声明：

“这就是为什么我们强烈鼓励开发人员在未来配备 Apple 芯片的 Mac 计算机的 kext 支持从 macOS 中删除之前采用系统扩展的原因”

因此，我们目前正在研究可能的替代方案。

Apple 建议迁移到系统扩展而不是 KEXT。但是，我们发现的唯一与 VFS 相关的 API 是实现一个基于 NSFileProviderReplicatedExtension 的文件提供程序。

不幸的是，NSFileProviderReplicatedExtension 有几个缺陷：

1. 文件可以在云端或下载。无法仅下载/读取文件的一部分。这对我们来说是一个很大的性能问题，因为我们使用大图像（> 1GB）。我们集成的程序通常只读取图像的一部分，例如嵌入式预览。 API 不提供访问文件的选定块（随机访问文件）的方法。
2. 文件提供程序通过 enumerators 了解文件系统内容。因此，必须首先枚举（列出）文件夹内的所有内容。否则无法访问。但是，我们无法枚举我们的 VFS。我们 VFS 的大部分内容都是完全动态的。它仅在客户端第一次访问时存在。此类动态内容还包括动态参数，例如客户端的区域设置或放置图像的框的大小。由于我们事先不知道这些参数，因此无法提前枚举 VFS 的内容。

这意味着，当前状态的 NSFileProviderReplicatedExtension 不能替代“真正的”VFS，因此我们不能将其用作当前 VFS KEXT 的替代品。

我的问题：

1. Apple 是否也允许在（基于 Apple Silicon/M1 的）操作系统的未来版本中进行内核扩展？或者至少有一个明确的截止日期？
2. 如果不是，Apple 官方建议的替代基于 KEXT 的 VFS 解决方案是什么？
3. NSFileProviderReplicatedExtension 的 API 是否会得到改进，使其表现得像一个“真正的”文件系统，以便上述缺陷不再成为问题？

非常感谢您的回答或评论！

最好的问候，

迈克尔

解决方法

Apple 是否也允许在（基于 Apple Silicon/M1 的）操作系统的未来版本中进行内核扩展？或者至少有一个明确的截止日期？

Apple 并没有真正给出时间表，而且他们偶尔也会违背支持承诺。

但是，这种硬 API 弃用和删除通常作为主要版本的一部分完成，因此您通常会在一年的 WWDC 上收到弃用通知，当操作系统的 .0 版本发布时，用户可能会开始看到弃用通知最早发布，有时是 .3 或 .4 修订版。然后，您通常会在 下一个 WWDC 上被告知 API 在即将发布的版本中被阻止，因此到那时您应该已经实现了替换。

如果不是，Apple 官方建议的替代基于 KEXT 的 VFS 解决方案是什么？

据我所知，目前只有 NSFileProviderReplicatedExtension。

是否会改进 NSFileProviderReplicatedExtension 的 API 使其表现得像“真正的”文件系统，以便上述缺陷不再是问题？

除了通过测试版 SDK 之外，Apple 通常不会预先宣布未来的 API。

我的建议：

• 您使用反馈助手遇到的每个文件提供程序缺陷的文件问题。 （雷达）
• 向 Apple 提交“增强请求”反馈问题，要求替换 VFS KPI 的“真实”文件系统 API。
• 如果您的 vfs kext 对您的业务/产品至关重要，我建议另外通过 TSI 询问 Apple 的 DTS，他们针对您的情况推荐什么。参考提交问题的反馈 ID，否则他们会建议您提交问题。