我遇到了以下现象，想知道 Windows 的文件系统抽象有多严重，或者是否涉及其他问题。
我对 MacBook Pro 的硬盘进行了分区，并安装了 Windows 7（64 位）。Boot Camp 驱动程序包中包含文件系统驱动程序，可让 Windows 访问 Mac OS HFS+ 分区。它是只读访问，但可以正常工作。
现在，我有一些我经常安装的东西的磁盘映像，所以我获取了一份 Daemon Tools 来安装它们。当我安装保存在 HFS+ 分区上的映像时，这些磁盘上大约三分之二的安装程序（通常是 InstallShield）会崩溃，并出现各种奇怪的错误。大多数都是胡言乱语，导致 Google 上出现各种非解决方案，其中一个是“此应用程序不适合您计算机的类型，请检查您是否需要 32 位或 64 位版本。”
将图像文件移动到网络上的另一台 Windows 7 计算机并从网络共享安装它们时，它们可以正常工作。
我现在的问题是，为什么应用程序的行为会根据只读图像文件，应该通过只读虚拟 Daemon Tools 驱动器抽象出来，位于只读 HFS+ 分区上还是位于 Windows 网络共享上？
我也会将这个问题纳入问题中，因为我想知道：网络共享的文件系统重要吗？客户端系统是否需要了解共享主机的文件系统，还是在 SMB 中将其抽象化了？
答案1
为什么应用程序的行为会有所不同，这取决于只读映像文件（应通过只读虚拟 Daemon Tools 驱动器抽象出来）是位于只读 HFS+ 分区还是位于 Windows 网络共享上？
我希望答案是“不稳定的 HFS+ 文件系统驱动程序”。如果当其中一个虚拟 ISO 安装失败时，您将 ISO 复制到本地 NTFS 驱动器，那么您将获得更好的测试。然后安装 NTFS 副本并重试安装 - 如果在那里失败，则说明您的 ISO 有问题；如果没有，则说明在离开 HFS+ 分区时读取错误。
不要忽视 ISO 不佳的情况。通过其他方式验证 ISO —— MD5 或 SHA 哈希值非常适合。
一个有趣的实验可能是计算一次哈希值，然后执行其他磁盘密集型操作（清除驱动器缓存），然后重复 10 或 20 次。如果您的 HFS+ 驱动程序无法正确读取，您将获得许多不同的值。
网络共享的文件系统重要吗？客户端系统是否需要了解共享主机的文件系统，还是在 SMB 中将其抽象化？
不是。SMB 文件共享提供自己的“文件系统”，称为SMB 或 CIFS对于客户端计算机（访问网络共享的计算机），CIFS 是文件系统。服务器计算机（提供网络共享的计算机）是唯一知道该共享下实际文件系统的系统（无论是 NTFS、FATx、ext2+、HFS+ 还是其他）。