3

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

因为看起来 KEXT 已被弃用，并且可能会在 macOS 的未来版本中完全删除，尤其是在基于 Apple Silicon 的计算机上。参见 Apple 在其 安全指南中的公告：

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

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

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 是否会被改进以表现得像一个“真实”的文件系统，从而使上述缺陷不再是问题？

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

最好的祝福，

迈克尔

4

2 回答 2

2

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

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

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

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

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

NSFileProviderReplicatedExtension 的 API 是否会被改进以表现得像一个“真实”的文件系统，从而使上述缺陷不再是问题？

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

我的建议：

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

关于您列出的第一个缺陷NSFileProviderPartialContentFetching，macOS 12.3 中提供了一个新协议。您的 FileProvider 应用程序扩展的主体类可以实现此协议，以支持文件的部分下载。

https://developer.apple.com/documentation/fileprovider/nsfileproviderpartialcontentfetching

于 2022-02-19T01:24:58.410 回答