FSEvent API删除事件未保留文件/文件夹大小写与标准化问题咨询

这个问题我之前做Mac备份工具时也碰到过，确实挺棘手的——FSEvents本质上是基于用户发起操作时用的路径字符串生成事件，不会主动回溯文件系统里原本的文件大小写，尤其是文件被删除后，系统也没法再查询原始路径信息了。结合HFS+和APFS的特性，给你几个实际可行的思路：

• 维护实时文件元数据索引
  这是最可靠的解决方案。在备份应用启动时，先对监控的根路径做一次全量扫描，用NSString的stringByStandardizingPath（或Core Foundation的CFURLCreateStringByStandardizingPath）生成每个文件的标准化路径，把这个路径和文件的实际大小写路径、inode等元数据存在本地索引里。之后每次收到FSEvents的创建/修改事件时，同步更新索引。当收到删除事件时，先把事件里的路径做标准化处理，再去索引里匹配对应的原始大小写路径，就能准确关联到备份里的文件了。
  注意要处理好索引的并发更新问题，避免多线程操作导致索引不一致。

• 区分文件系统的大小写敏感性
  APFS支持两种模式：默认的「大小写不敏感但保留大小写」，以及可选的「大小写敏感」。你可以通过statfs系统调用获取目标卷的属性，检查f_flags里是否包含MNT_CASE_SENSITIVE标记：

  struct statfs fsInfo;
  if (statfs("/", &fsInfo) == 0) {
      if (fsInfo.f_flags & MNT_CASE_SENSITIVE) {
          // 大小写敏感卷，事件路径就是实际路径
      } else {
          // 大小写不敏感卷，需要做标准化匹配
      }
  }
  

  针对不同卷类型做差异化处理，能减少不必要的索引匹配操作。

• 尝试利用文件系统缓存做路径解析（局限性较大）
  当收到删除事件时，你可以尝试用FSPathMakeRefWithOptions函数，传入kFSPathMakeRefCaseInsensitive选项去解析事件路径。如果文件系统缓存里还保留着该文件的元数据（比如刚删除不久），可能能拿到原始文件引用，进而通过FSRef获取原始路径。不过这个方法可靠性不高，只能作为补充手段，不能依赖它作为核心解决方案。

• 向Apple提交反馈
  既然官方文档没覆盖这个场景，而且备份工具这类应用非常依赖准确的文件路径信息，你可以通过Apple的反馈助手提交bug报告或功能请求，建议FSEvents在删除事件中携带原始文件的标准化路径（或原始大小写路径），尤其是在大小写不敏感的文件系统环境下。这类开发者反馈对Apple完善API很有帮助。

内容的提问来源于stack exchange，提问作者Suyash Singh