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

Question

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

看起来 KEXT 已被弃用，并且可能会在 macOS 的未来版本中完全删除，特别是在基于 Apple Silicon 的计算机上。请参阅 Apple 在其 安全指南中的声明：

“这就是为什么我们强烈鼓励开发人员在 macOS 中删除对未来采用 Apple 芯片的 Mac 电脑的 kext 支持之前采用系统扩展”

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

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

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

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

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

我的问题：

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

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

此致，

迈克尔

Answer 1

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

苹果并没有真正给出时间表，而且他们有时也会违反支持承诺。

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

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

据我所知，NSFileProviderReplicatedExtension目前是唯一的。

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

除了通过 beta SDK 之外，Apple 通常不会预先宣布未来的 API。macOS 13 更新： Apple 自己的一些文件系统驱动程序，包括“msdos”(FAT)，现在已在用户空间中实现。到目前为止，它使用的内核 API 尚未公开。

我的建议：

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