我在 Windows Server 2016 中有一个卷，它是数据重复数据删除角色的目标。
它运行得很好，节省率约为 60%，许多文件在磁盘上显示为零字节。
该卷通过 SMB 共享，可在 Mac、Windows 和 Linux 客户端上正常安装。后两者可以正常使用所有文件，但 Mac 不能。
对于任何显示为使用零磁盘空间的文件，Mac 都不知道如何读取它们。它们无法打开或读取，并且在 Finder 中复制会产生Error code -36。
在正常运行的客户端上，将文件复制到新客户端，使其尚未进行重复数据删除，这样 Mac 就可以读取它，因为它现在似乎占用了磁盘空间。例如，在 Ubuntu 上执行以下操作将导致文件失去优化：cp original_file.csv temp && mv temp original_file.csv
这是一个可以解决的问题吗，还是 macOS 或其实现 SMB 的方式存在问题？
答案1
在我看来，您似乎在 SMB 规范中发现了一个歧义。似乎 Finder 看到一个 0Bytes 的文件，并决定访问它毫无用处，因为它是空的。我可以看到自己在编写某些代码时很容易做出这样的选择，以尝试“优化”代码。Finder 的 SMB 实现是否存在问题？可能，但您必须非常仔细地阅读规范才能确定这一点！我会向 Apple 报告这个问题，因为我无法想象这不是一个错误。希望它最终会出现在错误列表中并很快得到修复。
顺便问一下，考虑到如今存储价格相对便宜，为什么还要使用压缩呢？
答案2
抱歉我来晚了。我确实经历过这种情况。但是当我调整 Windows Server 上的权限，将“Everyone”授予“完全控制”权限并在我想要共享的卷范围内启用继承时，似乎解决了这个问题。文件在磁盘上再次显示 0 字节，但我实际上可以访问重复数据删除后的数据。
或者您也可以在想要共享的文件夹范围内而不是卷范围内执行此操作，但我没有测试过这一点。
这可能是由于重新解析点的问题。
但是，如果您在整个卷上执行此操作，请务必禁用“系统卷信息”上的继承，以防止重复数据被破坏。在这里，我可以从 VMware Workstation 上的 macOS High Sierra VM 上的重复数据删除位置访问存储为 app.icns 的 Adobe Creative Cloud 图标文件
如果有人证实这种行为，我会很高兴。