我们为macOS上的虚拟文件系统(VFS)开发了 内核扩展(KEXT)看起来KEXT已经被弃用，可能会在未来的macOS版本中被完全删除，尤其是在基于苹果硅的计算机上。例如，请参阅苹果在其安全指南中的公告： "这就是为什么强烈鼓励开发人员在未来使用Apple silicon的Mac计算机的macOS中删除kext支持之前采用系统扩展的原因； 因此，我们目前正在调查可能的替代方案。 Apple建议迁移到系统扩展而不是KEXTs。然而，我们发现的唯一与VFS相关的API是实现一个基于NSFileProviderReplicatedExtension的文件提供程序。 不幸的是， 这意味着，处于其当前状态的 我的问题： 非常感谢您的回答或评论！ 致问候， MichaelNSFileProviderReplicatedExtension有几个缺陷：enumerators了解文件系统内容。因此，必须首先枚举(列出)文件夹中的所有内容。否则无法访问。然而，我们无法列举我们的VFS。我们VFS的大部分内容都是完全动态的。只有当客户端第一次访问它时，它才存在。这样的动态内容还包括动态参数，如客户端的区域设置或将放置图像的框的大小。由于我们事先不知道这些参数，因此无法提前枚举VFS的内容NSFileProviderReplicatedExtension不是"；真实的"；VFS，因此我们不能将其用作当前VFS KEXT的替代品。
苹果是否也允许在未来版本的(基于Apple Silicon/M1的)操作系统中进行内核扩展？还是至少有一个明确的截止日期？
苹果并没有真正给出时间表，他们偶尔也会违背支持承诺。
然而，这种严格的API弃用和删除通常是作为主要版本的一部分进行的，因此您通常会在一年的WWDC上收到它的弃用通知，用户可能会在操作系统版本的.0最早发布时开始看到弃用通知，有时还会看到.3或.4版本。然后，您通常会在下一次WWDC中被告知API在即将发布的版本中被阻止，因此此时您应该已经实现了替换。
如果不是，苹果官方建议用什么替代基于KEXT的VFS解决方案？
据我所知，NSFileProviderReplicatedExtension目前是唯一一个。
NSFileProviderReplicatedExtension的API是否会得到改进；真实的"；文件系统，使上述缺陷不再是一个问题？
除了通过测试版SDK，苹果通常不会预先宣布未来的APImacOS 13的更新：苹果自己的一些文件系统驱动程序，包括"msdos"；(FAT)现在在用户空间中实现。到目前为止，它使用的内核API还不是公共的。
我的建议：
- 您使用Feedback Assistant遇到的每个文件提供程序缺陷的文件问题。(雷达)
- 将一个"；增强请求"；与苹果的反馈问题；真实的"；文件系统API替换VFS KPI
- 如果你的vfs kext对你的业务/产品至关重要，我建议另外通过TSI询问苹果的DTS他们对你的情况有什么建议。请参考已提交问题的反馈ID，否则他们将建议您提交问题
关于您的障碍：
- 有一个NSFileProviderPartialContentFetching，它允许部分提取项的内容
- 枚举只是告诉文件和文件夹的系统，就像使用Finder浏览本地文件系统一样。你告诉系统的内容在你的控制之下，你可以传递你用一个参数检索到的元数据，比如你的客户端的区域设置代码。也许你可以详细说明这是一个障碍。根据你的描述，它应该还是可行的
我要求NSFileProviderReplicatedExtension表现得像"；真实的"；文件系统，因为它实际上向macOS提供了远程存储的元数据，然后macOS在本地实际文件系统中重建该状态。因此，最后您在~/Library/CloudStorage/<whatever-domain>中用(可选)"浏览实际的文件系统；占位符"；文件(非物质化项目)。