Why do disk images hosted on a read-only HFS+ partition behave differently?

Question

I have come across the following phenomenon and would like to know how leaky Windows' file system abstraction is or if there's something else involved.

I partitioned the hard disk of my MacBook Pro and installed Windows 7 (64 bit). The Boot Camp driver package includes file system drivers that enable Windows to access the Mac OS HFS+ partition. It's read-only access, but it works.

Now, I have some disk images of stuff I usually install, so I grabbed a copy of Daemon Tools to mount them. When I mount an image saved on the HFS+ partition, about two out of three installers on these disks (usually InstallShield) crash with all sorts of weird errors. Most are just gibberish that lead to all sorts of non-solutions on Google, one was "This application is not the right type for your computer, check if you need 32 or 64 bit versions."

When moving the image files to another Windows 7 computer on the network and mounting them from the network share, they work fine.

My question now is, why do applications behave differently depending on whether the read-only image file, which should be abstracted away through the read-only virtual Daemon Tools drive, is located on a read-only HFS+ partition or on a Windows network share?

And I'll just roll this into the question as well since I was wondering: Does the file system of a network share matter? Does the client system need to understand the file system of the share host or is that abstracted away in SMB?

Answer 1

why do applications behave differently depending on whether the read-only image file, which should be abstracted away through the read-only virtual Daemon Tools drive, is located on a read-only HFS+ partition or on a Windows network share?

I expect the answer is "flaky HFS+ filesystem drivers". You'll get a better test if, when one of these virtual-ISO-installs fails, you copy the ISO to the local NTFS drive. Then mount the NTFS copy and retry the installation -- if it fails there, you've got a bad ISO; if it doesn't, you're getting bad reads when coming off the HFS+ partition.

And don't discount the bad-ISO scenario. Verify the ISO through some other means -- MD5 or SHA hashes are good for that.

An interesting experiment might be to calculate the hash once, then do something else disk-intensive (to clear drive cache), then repeat 10 or 20 times. If your HFS+ drivers aren't getting the reads right, you'll be getting a lot of different values.

Does the file system of a network share matter? Does the client system need to understand the file system of the share host or is that abstracted away in SMB?

Not really. SMB fileshares provide their own "filesystem" called SMB or CIFS. To the client computer (the one accessing the network share), CIFS is the filesystem. The server computer (the one providing the network share) is the only system aware of the actual filesystem underlying that share (be it NTFS, FATx, ext2+, HFS+, whatever).